HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Atoptool
atop
C2025–2025
Atoptool / atop

atop

System and process monitor for Linux

8Distinct people
11Mentions
0Explicit recommenders
1.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

System and process monitor for Linux

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by week11 dated mentions

Observed mentions: 2025-03-26 00:05:29 UTC to 2025-07-30 12:44:50 UTC. Weeks start Monday, UTC.

02468102025-03-24 00:00:00 UTC to 2025-03-31 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 commentsMar 242025-03-31 00:00:00 UTC to 2025-04-07 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-04-07 00:00:00 UTC to 2025-04-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-04-14 00:00:00 UTC to 2025-04-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-04-21 00:00:00 UTC to 2025-04-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-04-28 00:00:00 UTC to 2025-05-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-05 00:00:00 UTC to 2025-05-12 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-12 00:00:00 UTC to 2025-05-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-19 00:00:00 UTC to 2025-05-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-26 00:00:00 UTC to 2025-06-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMay 262025-06-02 00:00:00 UTC to 2025-06-09 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-09 00:00:00 UTC to 2025-06-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-16 00:00:00 UTC to 2025-06-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-23 00:00:00 UTC to 2025-06-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-30 00:00:00 UTC to 2025-07-07 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-07-07 00:00:00 UTC to 2025-07-14 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-07-14 00:00:00 UTC to 2025-07-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-07-21 00:00:00 UTC to 2025-07-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-07-28 00:00:00 UTC to 2025-08-04 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 commentsJul 28

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Mar 242025-03-24 00:00:00 UTC2025-03-31 00:00:00 UTC909
Mar 312025-03-31 00:00:00 UTC2025-04-07 00:00:00 UTC000
Apr 72025-04-07 00:00:00 UTC2025-04-14 00:00:00 UTC000
Apr 142025-04-14 00:00:00 UTC2025-04-21 00:00:00 UTC000
Apr 212025-04-21 00:00:00 UTC2025-04-28 00:00:00 UTC000
Apr 282025-04-28 00:00:00 UTC2025-05-05 00:00:00 UTC000
May 52025-05-05 00:00:00 UTC2025-05-12 00:00:00 UTC000
May 122025-05-12 00:00:00 UTC2025-05-19 00:00:00 UTC000
May 192025-05-19 00:00:00 UTC2025-05-26 00:00:00 UTC000
May 262025-05-26 00:00:00 UTC2025-06-02 00:00:00 UTC000
Jun 22025-06-02 00:00:00 UTC2025-06-09 00:00:00 UTC000
Jun 92025-06-09 00:00:00 UTC2025-06-16 00:00:00 UTC000
Jun 162025-06-16 00:00:00 UTC2025-06-23 00:00:00 UTC000
Jun 232025-06-23 00:00:00 UTC2025-06-30 00:00:00 UTC000
Jun 302025-06-30 00:00:00 UTC2025-07-07 00:00:00 UTC000
Jul 72025-07-07 00:00:00 UTC2025-07-14 00:00:00 UTC000
Jul 142025-07-14 00:00:00 UTC2025-07-21 00:00:00 UTC000
Jul 212025-07-21 00:00:00 UTC2025-07-28 00:00:00 UTC000
Jul 282025-07-28 00:00:00 UTC2025-08-04 00:00:00 UTC202

What Hacker News says

11 sources
A bug matching the details of the vaguepost was found by a third party with no help from Rachel: https://blog.bismuth.sh/blog/bismuth-found-the-atop-bug > Given the vagueness, we were curious if Bismuth's bug scanning capabilities could find the bug so we let it rip on the code base. 10 minutes later, we had it. Or at least we had a bug which looked and behaved exactly like Rachel described. > As soon as we figured this out and had something reproducible we moved to responsibly disclose the issue and we emailed Gerlof at 8pm on the 26th. > Seeing this bug and how it's triggered, I understand Rachel's initial reaction to write a vague "get rid of it" post without going into detail. [...] That said, the internet loves to run wild with speculation and there's a reason we have the responsible disclosure process. For something that's installed
Read the rest
as often as Nvidia GPU drivers, it would be prudent to spend the extra few days and have a controlled disclosure. Posting something like that can start off an arms race to find the bug, and if someone malicious were to reproduce and exploit it first, they get free reign to take over affected systems until it's patched. Yes, sounding the alarm might cause people to uninstall it, but there's plenty of places where it will remain, giving malicious actors incentive to go for it. But with a coordinated disclosure, the arms race never starts, and systems are patched before anyone realizes there was an issue. The atop maintainer fixed the bug on March 29th, and also changed the behaviour of atop to _not_ connect to its helper daemons by default: https://github.com/Atoptool/atop/commit/542b7f7ac52926ca2721... ... and released it as atop v2.11.1 on April 5th: https://github.com/Atoptool/atop/releases/tag/v2.11.1 There has been nothing on Rachel's blog about this topic since the vaguepost and vaguepost followup. The CVE (https://www.cve.org/CVERecord?id=CVE-2025-31160) is still incorrect, and there's no indication who requested it. It says that versions "0 - 2.11.0" are affected, this is untrue, because the atopgpud (and support in atop for reading from it) was introduced in version 2.4.0 ("The vulnerability is present since the introduction of 'atopgpud' in atop 2.4.0." per https://www.atoptool.nl/downloadatop.php)
In Project Zero – Policy and Disclosure: 2025 Edition
I stand by what I said at the time: https://news.ycombinator.com/item?id=43492940 - and if you only read one thing, read the harrassment an atop contributor was subjected to by "eslerm": https://github.com/Atoptool/atop/issues/330#issuecomment-275... I bring it up because of the unmissable parallels. Google are trialling a policy to see what will happen, but this incident shows already what can happen. RbtB is a trusted blog by the HN crowd, and her vaguepost unexpectedly whipped up hysteria. It was only quelled by a post with more details the next day. Google Project Zero has enormous levels of trust, intends to vaguepost as policy, and not post more details the next day to satisfy the mob. It does not look good for volunteer maintainers to suffer an entire world of talentless clowns rifling through every commit and asking "is this the b
Read the rest
ug Project Zero found?"
In Project Zero – Policy and Disclosure: 2025 Edition
> if you're not already root Hmm, good point. I think we made opposite assumptions about that. If the daemon does run as a root, then no extra software is required. For Unix domain sockets, you can trivially create your socket in /run, and for TCP, you can trivially use a port below 1024. If it doesn't, then some extra software or configuration is required in either case. I tried looking it up, and I think it does run as root[1]. But I also found that the daemon uses a Python library to get GPU stats, and root might or might not be required depending on how the GPU software is configured[2]. So it could have gone either way. --- [1] That's how I read this: https://github.com/Atoptool/atop/blob/master/atopgpu.service [2] See https://github.com/gpuopenanalytics/pynvml/issues/19
In Atop 2.11 heap problems
Fingerpointing is bad, but we have to have an honest conversation. One person posted the vague post. They clearly did not expect the reaction it got, though they could have anticipated some of it, they are aware their blog is widely read. Their reaction is commendable, to quickly post a followup appealing for calm and sharing some details, to quell the problems caused by the intense vagueness. What people from HN did, because of the vagueness, was assume this a super-secret-squirrel mega-vulnerability and Rachel is gagged by NDAs or the CIA or whatever... and they've gone off and harrassed the developers of atop while trying to find the issue. Imagine a person of note saying "the people at 29 Acacia Road are suspicious", then a mob breaks down the door and start rifling through all the stuff there, muttering to themselves "hmm, this lamp
Read the rest
looks suspicious... this fork looks suspicious"... absolute clowns, all of them. For example, this asshole who went straight in there with bad-faith assumptions on the first thing they saw: https://github.com/Atoptool/atop/issues/330#issuecomment-275... No, you dummies, it's not going to be in the latest commit, or easily greppable. This is exactly why CVEs, coordinated disclosure, and general security reporting practises exist. So every single issue doesn't result in mindless panic and speculation. There's now even a CVE purely based on the vaguepost, assigned to a reporter who clearly knows fuck all about what the problem is: https://www.cve.org/CVERecord?id=CVE-2025-31160 - versions "0" through "2.11.0" vulnerable, eh? That would be all versions, and the reason the reporter chose that is because they don't know which versions are vulnerable, and they don't know what it's vulnerable to either. But somehow, "don't know", the absence of information, has become a concrete "versions 0 to 2.11.0 inclusive"... just spreading the panic. I don't know why Rachel is vagueposting, but I can only hope she has reported this correctly, which is to: 1. Contact the security of the distro you're using. e.g. if you're using atop on debian, then email security@debian.org with the details. 2. Allow them to help coordinate a response with the packager, the upstream maintainer(s) if appropriate, and other distros, if appropriate. They have done this hundreds of times before. If it's critically important, it can be fixed and published within days, and your worries about people being vulnerable because you know something they don't can be relieved, all the more quickly.
In Problems with the heap
No one else seems to have run 'grep system(', so I will: https://github.com/Atoptool/atop/blob/037a6d3e4ace6c7be6c5dc... > system ("gunzip -c %s > %s", tmpname1, tmpname2") tmpname2 is hardcoded as "/tmp/atopwrkXXXXXX", so that's fine. tmpname1 is '$irawname.gz'. '$irawname' is set by the '-r' flag. So, presumably if you can get the rest of the code to play nice and get you there, you can escalate from having shell access to run atop, to having shell access. Oh, I guess that's nothing. Anyway, still a really bad use of system + user-controlled input, don't do that.
In You might want to stop running atop

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.