Tuesday's cryptic message about atop turns out to be a local memory corruption issue, but details are unclear:

https://www.openwall.com/lists/oss-security/2025/03/26/2

What is clear to me is that the original "warning" was a shameful example of spreading FUD...

CVE-2025-31160 was issued to track the problem.

@buherator seemed like hype machine food or like the author of the original blog was maybe unfamiliar with the responsible disclosure process; the latter *could be* the case but I’ve been following that blog since I was in college, so it seems surprising to me its author would have no idea how to report a vuln and get it properly addressed before disclosure

@kaoudis I have plenty of experience with technically competent people messing up 1) risk assessment 2) communication, so I'd write this off as incompetence, but that should be called out too (esp. since based on the latest post they seem to think they've done everything right).

@buherator fair enough; neither is easy!

@buherator *thinking about all the collective time spent today to patch this bug because dependency scanner are surfing on the FUD*

@buherator i see your point, and i agree. but from a different perspective i also see that this project got a lot of scrutiny that it wouldn't have gotten otherwise, some skeletons were falling out of the closet, and that is good. maybe this is not the right way (quite possibly) but i think it is good if we all focus our attention from time to time on a project that is otherwise mature and forgotten because it just works.

@stf The more I work in security the more I feel like being part of a large scheduling algorithm: we discover some information, associate some risk, then people will end up workin on some specific stuff. If we cause priority inversion, starvation, etc. then we are a bad scheduler.

In this case:
- The original recommendation ("uninstall it!") turned out to be totally unsubstantiated, we can by all means call it misinformation
- Secrecy about details added to the fear and also *actively misdirected efforts* both at level of security teams and at devs/researchers (see the confusion about #330 & people looking at new commits to find backdoors)

Since no significant new attack surface/vector was presented I don't even think the code will get that much of scrutiny as exploitability is pretty low (local with user interaction).

In the end, the cost-benefit analysis looks really bad to me.

@buherator great analysis, can't nod more violently ;) but my generic point that drawing hype(r)-focused attention from time to time to forgotten but widely used mature tools would be beneficial. the scheduling algorithm does not very much schedule them ever. but yeah, better target selection (at least running suid, or remote input) would improve the cost/benefit analysis.