@orange_lux Not top, atop.
@orange_lux Happens to the best of us!
I assume that's the Linux process monitor and not the industrial automation toolset.
<Grabb0rs the current source for reference>
to be clear “atop” is a Linux system administration tool and if you don’t know what that means or if you could possibly have it installed, you don’t.
@0xabad1dea an update to the atop thing!
@0xabad1dea Some additional info here: https://rachelbythebay.com/w/2025/03/26/atop/
It sounds like the contributor folks have been dogpiling has little or nothing to do with Rachel's warning, but rather a more troubling and long-lived bug has been noticed.
At a guess, I expect the routine that compares the current process/thread snapshot with the previous one has a buffer length variable that doesn't get set properly, leading to some sort of over/underrun scenario.
@0xabad1dea Rachel hints that this is something that can be triggered by an unprivileged user. Maybe manipulating the process table by exec/exit processes during the interval between atop's `/proc` reads? Or rolling over the `pid_max` to exploit some assumption `atop` makes about following processes across scans?
I'm really interested in what folks dig up with all this attention on atop. I've always just tolerated its jankiness because it's so useful, but it is janky fo sho.
@0xabad1dea OK, let's check the changelogs at atoptool.nl/downloadatop.php ... oh, found something for version 2.11.0:
A temporary raw file you say? May it be that it accidentally dumps information that shouldn't be accessible to unprivileged users?