If you'd asked me, when I created the question, if a privilege escalation would qualify, I would've said NO. But I think for a majority of people betting they would've guessed a YES, so I N/Aed

Not ideal, but was just a little market for fun, so whatever

it doesn't look we needed to uninstall atop https://rachelbythebay.com/w/2025/03/25/atop/

wow, a ... local privilege escalation ...

@jacksonpolack I mean, still severe?

@jacksonpolack were you expecting something else? The vast majority of vulns in privileged components that are themselves neither network servers nor clients are going to be LPE. And that doesn't mean "unimportant" (consider things like container escapes).

That second post doesn't even necessarily mean "can't be exploited remotely", though. We don't know what the attack vector is. It could be something - like a pattern of memory allocations - that an attacker could plausibly induce a server, client, or JS sandbox to trigger (the last is arguably "local" EoP but the exploit is from a remote source and runs without exicit user interaction, I'd say it counts as remote).

@SeekingEternity https://openwall.com/lists/oss-security/2025/03/29/1

This looks exploitable for an attacker who can listen on a TCP port on localhost.

I would consider the warning marginally justified overall. atop clearly has, or had, a pattern of attempting to connect to additional data sources (e.g. atopgpud), without validating that they are actually trusted, and then speaking bespoke IPC protocols with them using parsers written in buggy C. As far as I know, other top alternatives do not do this - so uninstalling atop may have been a reasonable recommendation.

But the original blog post was also clearly unjustified, or at least poorly thought out. The author should have known that their words implied a significantly worse issue, and that they would result in a panic. A close friend of mine, who works in security, gives the attacker's perspective:

--- quote

thinking through how i'd actually use this, the big issue is... you need somebody to actually run atop. like for a while we thought it was "oh there's an exploitable SUID binary" which, yeah, would still be 'just' LPE but would be a much /worse/ one than this. because if i got unprivileged shell on a box w/ atop on, i could run some generic exploit & get root.

but here it's like, oh, i can listen on a tcp port i guess, which is noisy and visible, or watch procfs maybe for anybody spawning atop & try to race it? that's just not that useful, a privesc that works maybe weeks or months after you set up the exploit is a gimmick at most i think. so if atop is installed suid on your distro, that's probably worth worrying about, but from what i see that's a pretty uncommon configuration? otherwise if it's "an attacker is patiently waiting until the next time you run atop to escalate their privileges" that's just a weird little bug and not worth freaking out about at all lol

--- endquote

@Twig Jesus FUCKING Christ, people, STOP USING UNAUTHENTICATED LOOPBACK NETWORK SOCKETS FOR LOCAL IPC what is WRONG with you?!?

...which is to say, thanks for the link! Yeah that's definitely a easy local EoP vector. Cross-user, and potentially cross-container. And may I just ask once again what the FUCK a kernel module is doing running a TCP server??

---

As for the part about the justification of the problem, apparently at least some fairly common distro automatically start atop, running privileged, for logging. So (assuming the kernel module isn't in use and the port is free), you'd get connection and thus presumably privesc, maybe even code exec, immediately. This is arguably a fault of your distro making bad choices but, you know, they do that sometimes.

Thank you very much for the information Given that some distros start atop automatically, there was clearly a nontrivial risk of privilege escalation here, and uninstalling atop was a reasonable call to make at the time.