Hey guys we commented on another thread from a few days ago about our tool Bismuth finding the bug (along with a sha of our reproducer script for proof)
<a href="https://news.ycombinator.com/item?id=43489944">https://news.ycombinator.com/item?id=43489944</a><p>After disclosing and having correspondence with Gerlof and from his above post it looks like we did in fact nail it and I've just shared our write up on how we got it.<p>HN post detailing how we got it: <a href="https://news.ycombinator.com/item?id=43519522">https://news.ycombinator.com/item?id=43519522</a><p>Edit: Here's our reproducer and we've added it to the post too: <a href="https://gist.github.com/kallsyms/3acdf857ccc5c9fbaae7ed823be0365e" rel="nofollow">https://gist.github.com/kallsyms/3acdf857ccc5c9fbaae7ed823be...</a>
This doesn't seem nearly as nefarious as the post from earlier this week indicated... I had expected a full supply chain compromise or something that bad based on the earlier post.
I was bit by atop a few years back and swore it off. I would get perfectly periodic 10m hangs on MySQL. Apparently they changed the default runtime options such that it used an expensive metric gathering technique with a 10m cron job that would hang any large memory process on the system. It was one of those “no freaking way” revelations after 3 days troubleshooting everything.<p>Interesting reading through the related submission comments and seeing other hard to troubleshoot bugs. I don’t think atop devs are to blame, my guess is that what you have to do to make a tool like atop work means you are hooking into lots of places that have potential to have unintended consequences.
Ah, there's the other shoe:)<p>> optional sources, that have to be activated explicitly.<p>So only locally exploitable, and you have to enable an optional feature? That's ... honestly better than I was worried that it might be
> The vulnerability is caused by the fact that atop always tries to connect
to the TCP port of 'atopgpud' during initialization. When another local
program has been started (instead of 'atopgpud') that listens to this TCP
port, atop connects to that program. Such program is able then to send
unexpected strings that may lead to parsing failures in atop. These failures
result in heap problems and segmentation faults.<p>Okay, so, if I have a shell and the rights to listen on a host, I can crash the "atop" of other users? That's it ? I could also create a fork bomb, fill up the disk, use all CPU and memory, etc...
I have a semi-related question.For someone whose main job is not maintaining or running full linux servers but would like information about processes and their RAM/CPU..etc. What would be a good tool that is easy to parse with good defaults?
So, as <a href="https://www.cve.org/CVERecord?id=CVE-2025-31160" rel="nofollow">https://www.cve.org/CVERecord?id=CVE-2025-31160</a> says:<p>* CWE-617 Reachable Assertion<p>* affected from 0 through 2.11.0<p>... can we assume these will be updated to the actual vulnerability (CWE-940, CWE-120?), and vulnerable versions (2.4.0 through 2.11.0)? Or was the vaguepost about an entirely different vulnerability? Does anyone yet know what specific issue the vaguepost was alluding to?
> the parsing of the strings is improved to avoid that heap problems can occur.<p>Tell me what language you’re using without telling me what language you’re using…
atop freaks out if it isn't talking to the thing it thinks it's talking to... who would have thunked it... I feel like a lot of programs have that issue.