Introduction: Atop mainly reads the system level and process level from the /proc and /sys directories. However, certain counters might be obtained from other optional sources, that have to be activated explicitly.

One of these sources is the 'atopgpud' daemon, which permanently gathers metrics about the utilization of GPUs. It offers a local TCP port to which atop can connect to retrieve GPU-related counters. These counters are provided as strings that have to be parsed by atop.

Vulnerability: 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.

Although no additional information has been received about these heap problems, the described heap problems were reproduced with a custom developed test program.

The vulnerability is present since the introduction of 'atopgpud' in atop 2.4.0.

Solution: 1) Most systems will not explicitly activate the 'atopgpud' daemon.    Therefore, the default behavior of atop is now not to connect to the TCP    port at all. Only when atop is started with the '-k' flag it will try to    connect to the TCP port (in case you know that 'atopgpud' is running).

2) When the '-k' flag is used, the parsing of the strings is improved to    avoid that heap problems can occur.

3) Another optional source for atop might be 'netatop' or 'netatop-bpf'.

On Thu, Mar 27, 2025 at 12:17 AM Thomas Ward <teward () thomas-ward net> wrote: Not sure if MITRE is on this list, but...

On 2025-03-26 19:56, Alan Coopersmith wrote: CVE-2025-31160 appears to have been issued by Mitre to track this:

https://www.cve.org/CVERecord?id=CVE-2025-31160

but only listing the above blog and the ycombinator threads for details. ... this should include a link to https://github.com/Atoptool/atop/issues/330 which is a tracker for the issue in this CVE. It looks like a munmap patch has been provided but it looks also that this may be one of multiple 'suspicious' commits on the radar (if you read the issue thread). Have you linked the wrong issue? This is the premature accusation that doesn't match the symptoms and isn't likely to be in any distros. So it's probably not worth linking to the CVE.

Mark

On 3/26/25 16:07, Solar Designer wrote: Hi,

This (or rather an earlier vague warning) made it to various tech news sites today:

https://rachelbythebay.com/w/2025/03/26/atop/ CVE-2025-31160 appears to have been issued by Mitre to track this:

https://www.cve.org/CVERecord?id=CVE-2025-31160

but only listing the above blog and the ycombinator threads for details.

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Hi,

This (or rather an earlier vague warning) made it to various tech news sites today:

https://rachelbythebay.com/w/2025/03/26/atop/ Wednesday, March 26, 2025 Problems with the heap [...] Now, first off, I don't know exactly how to exploit this sort of thing. I was there in the 90s when this overflow stuff started popping off, and I'm pretty sure that if you can do this, you can do much worse.

This is what I'm talking about:

Terminal 1:

user1$ random-tool

Terminal 2:

user2$ atop malloc(): corrupted top size Aborted

... that's pretty bad, right?

So you twiddle the tool a little bit and go again and...

user2$ atop Segmentation fault

That's not great, either!

Or... how about...

user2$ atop Fatal glibc error: malloc assertion failure in sysmalloc: (oldtop == initialtop (av) && oldsize == 0) || ((unsigned long) (oldsize) >= MINSIZE && previnuse (oldtop) && ((unsigned long) oldend & (pagesize - 1)) == 0)

Again, this is not my world. I've never written a heap exploit, but reading about it briefly makes me think that there's meat on these bones.

user1 does something... and gets user2 to blow up. If you can make that do something useful, then you get user2 to run stuff on your behalf.

What if user2 is root? Then you own the box.

Okay? So maybe stop running it as root, but also just stop running it. Some people on various forums are now looking at recent atop commits:

https://github.com/Atoptool/atop

but none appear relevant - indeed, the above doesn't look like it was investigated nor reported properly, so there isn't expected to be a fix in the repo yet.

With no specific published reproducer, I suggest someone from this community try and identify one (fuzzing?) and publish it this time. Then the issue(s) could be investigated and fixed.

Indeed, fixing individual issues may not be enough to make atop safe to use (the codebase is arguably too large for what it does, and code quality poor), but that's what's being done to other software in such cases (e.g., "similar" bugs also existed in procps-ng and were fixed).

Alexander

httpd.c in atophttpd 2.8.0 has an off-by-one error and resultant out-of-bounds read because a certain 1024-character req string would not have a final '\0' character.

atop through 2.11.0 allows local users to cause a denial of service (e.g., assertion failure and application exit) or possibly have unspecified other impact by running certain types of unprivileged processes while a different user runs atop.