Details about CVE-2025-31160 (memory corruption in #atop) are now available here: https://github.com/Atoptool/atop/issues/334
In a nutshell: atop at startup connects to local (non-privileged) TCP port 59123 where it expects certain data; if a regular user listens on that port, it can feed data to the next invocation of atop that can corrupt it.
The fix (https://github.com/Atoptool/atop/commit/542b7f7ac52926ca272129dba81d7db80279bb98) is primarily "don't do that" with some attempt at better parsing of the untrusted data (by adding return code checking of `sscanf`).
I saw it, and I agree with people's response to "This is not the way to do this.", which was: "Then why did you do it that way, then?"
I've just installed #atop on #sydbox #ctf server in case people want to explore exploiting the recent heap corruption. I don't trust jia tan enough to leave atop.service running as root though so the attack vector is limited. Sail with #ssh to syd.chesswob.org (user/pass: syd) or go to https://syd.chesswob.org although the #nodejs client is a bit more limited. See here for the #security issue, https://www.openwall.com/lists/oss-security/2025/03/26/2 (tl;dr uninstall #atop asap!) and here for #sydbox #ctf https://ctftime.org/event/2178
Glanced at a little #atop code. Found two vulns. The NULL PTR deref likely can only be triggered by exploiting the TOCTOU race condition.
There are a lot of potential vulnerability loci.
It could even be a privacy thing. Arch users get the whole package, which includes an atopgpud that sends GPU statistics over TCP out to anyone who asks, and has no connection limiting or transaction timeout capabilities. (This isn't packaged in Debian.)
My educated guess is the kernel module or the dæmon having some serious problem. The command-line tool isn't set-UID, as far as I can see. (I'm just going off the package install recipes. I don't have it installed.)
@catsalad @puppygirlhornypost2 @Emily
Also note that there are different #atop packages around.
Might be excessive.
The #atop used in #FreeBSD is a different one to the one used by Linux distributions (& #NetBSD/#OpenBSD have no atop in ports/packages at all).
FreeBSD sysutils/atop in the ports tree uses a FreeBSD codebase maintained by Alex Samorukov. It has no kernel module/atopacctd.
https://freshports.org/sysutils/atop/
https://github.com/samm-git/atop-freebsd
Arch/Debian instead track Gerlof Langeveld's atoptool, which has a kernel module/BPF hooks & an atopacctd.
Do you have a Linux /*BSD/other kind of Unix-y type machine?
(Edit: not BSD, thanks @JdeBP)
Do you have the process monitor software "atop" installed.
Best you don't.
Im not uninstalling #atop from the hospital servers until I get a proper reason.
@nixCraft I don't. But I do love atop or, as I like to call it, the ultimate consultant tool…
@avatter Wenigstens konsequent: #atop auf #raspberry, so muss Lagezentrum. :)