New Moderate Linux Flaw Allows Password Hash Theft Via Core Dumps in Ubuntu, RHEL, Fedora

An anonymous reader shared this report from The Hacker News: Two information disclosure flaws have been identified in apport and systemd-coredump, the core dump handlers in Ubuntu, Red Hat Enterprise Linux, and Fedora, according to the Qualys Threat Research Unit (TRU).

Tracked as CVE-2025-5054 and CVE-2025-4598, both vulnerabilities are race condition bugs that could enable a local attacker to obtain access to access sensitive information. Tools like Apport and systemd-coredump are designed to handle crash reporting and core dumps in Linux systems. "These race conditions allow a local attacker to exploit a SUID program and gain read access to the resulting core dump," Saeed Abbasi, manager of product at Qualys TRU, said...

Red Hat said CVE-2025-4598 has been rated Moderate in severity owing to the high complexity in pulling an exploit for the vulnerability, noting that the attacker has to first win the race condition and be in possession of an unprivileged local account... Qualys has also developed proof-of-concept code for both vulnerabilities, demonstrating how a local attacker can exploit the coredump of a crashed unix_chkpwd process, which is used to verify the validity of a user's password, to obtain password hashes from the /etc/shadow file.
Advisories were also issued by Gentoo, Amazon Linux, and Debian, the article points out. (Though "It's worth noting that Debian systems aren't susceptible to CVE-2025-4598 by default, since they don't include any core dump handler unless the systemd-coredump package is manually installed.")

Canonical software security engineer Octavio Galland explains the issue on Canonical's blog. "If a local attacker manages to induce a crash in a privileged process and quickly replaces it with another one with the same process ID that resides inside a mount and pid namespace, apport will attempt to forward the core dump (which might contain sensitive information belonging to the original, privileged process) into the namespace... In order to successfully carry out the exploit, an attacker must have permissions to create user, mount and pid namespaces with full capabilities." Canonical's security team has released updates for the apport package for all affected Ubuntu releases... We recommend you upgrade all packages... The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This service:

- Applies new security updates every 24 hours automatically.
- If you have this enabled, the patches above will be automatically applied within 24 hours of being available.

A-Z

[markdavis]

If you can do A and B while C and D if E and F but not G to H when I is J then maybe K will hit L until M, N, and O do P which allows you possible access to Q which if R and S are T then U might be able to V as long as W isn't X then you have a slight chance that Y will allow partial access to Z.

Re:A-Z

[YetAnotherDrew]

Spoken as a true man of letters.

I was worried for a second

[Anonymous Coward]

Disable that gnome and systemd shitware.

This isn't a vulnerability in 'Linux'.

Re:

[thegarbz]

You disabled systems for a CVE that relies on an attacker to already have privileged access to your system? I think it's time you go check the expiry date on all your prepped cans in your disaster bunker.

Re:I was worried for a second

[gweihir]

Hahaha, no. This is a moment were people that do not run the systemd crap get to say "I told you so". Again.

Re:

[brickhouse98]

Yes because there are never vulnerabilities in software other than systemd. By god the anti-systemd people need to just give it up already. You don't like it? Fine, no one gives a shit. Just stfu already and run sysv or whatever.

Re:I was worried for a second

[drinkypoo]

You don't like it? Fine, no one gives a shit.

Many of us do.

Just stfu already

Oh look, you think you're the boss. Adorbs.

Re:

[thegarbz]

No you're the boss. Of your system. Do with it what you want, leave the rest of us alone. No one is forcing you to run systemd, so drop the religious preaching. The reality is that this entire thing is a nothingburger and pretending this is a meaningful security risk given the level of access required is just a continued demonstration of the absurd lack of critical thinking on the topic whenever someone mentions systemd.

Sometimes I wish this was the 30s where we could simply slap people and tell them to sto

Re:

[gweihir]

And, obviously, the assholes that modded me down are clueless cretins as well. (Go on, waste your mod-points on somebody pointing out your deficiencies. As if they would go away if you do that ... )

Re:

[93 Escort Wagon]

It reminds me of the Windows Vista days... how Microsoft finally decided to get rid of all the BSD underpinnings they'd relied on for 15-20 years, followed by us seeing very old vulnerabilities that'd been solved in Unix space long before suddenly popping up again - repeatedly - in Windows.

Re:

[gweihir]

This is 100% on Pottering's System==D. It's not a "Linux" problem, it's a System==D problem.

Yep. And an entirely predictable one. Poettering and his ilk are incompetent fuckups with delusions. And thair disciples are not much better. Morons. Solid engineering looks different.

Re: I was worried for a second

[reanjr]

Except the Debian example undermines all those people who complain that systemd is monolithic and demonstrates that systemd is properly modularized.

Re:

[thegarbz]

Hahaha, no. This is a moment were people that do not run the systemd crap get to say "I told you so". Again.

What did you tell me? A low risk CVE that can only be exploited by someone who has privileged enough access to the system to modify user and process credentials is a problem? Hey someone, can I get a whoopdefuckingdo in here? I need a whoopdefuckingdo stat!

Re: I was worried for a second

[drinkypoo]

setuid programs provide privileged access by definition

Re:

[vbdasc]

Your parent commenter said "This isn't a vulnerability in 'Linux'.". And he/she is absolutely correct. Who the hell even writes these article summaries? The FUD-master at Microsoft?

Re: I was worried for a second

[drinkypoo]

Whether we like it or not, "Linux" means both the kernel and typical unixlike OS distributions which are based on it, and typically refer to themselves as some kind of Linux. Readers are expected to be able to differentiate. The general public doesn't care, and we technical types have enough experience to know which is meant, so we should have no problem.

Re:

[vbdasc]

I disabled systemd in my Debian servers because I can't stand it, and because the attack and bug surfaces it carries are absolutely huge and I can't justify getting that negative baggage. Not due to some particular CVE, but due to thousands of potential CVEs.

Re:

[drinkypoo]

Pussy offers me something I want, while systemd takes away things I want, like early boot logging.

Mitigation

[Vomitgod]

as per openwall.com -

To mitigate these vulnerabilities, /proc/sys/fs/suid_dumpable can be set
to 0 (SUID_DUMP_DISABLE, "No setuid dumping").

This prevents all SUID programs and root daemons that drop privileges from being analysed in
case of a crash, but it can act as a temporary fix if the vulnerable
core-dump handler itself cannot be patched immediately.

BETTER Mitigation

[storkus]

Thank $DIETY that I use SystemD-free Slackware!

*ducks & pulls down asbestos suit hood*

Re:

[gweihir]

Non-systemd Debian and more and more Devuan here. This is not a high criticality vulnerability, but, after the sshd near-disaster, the second time not running systemd proves to be the right decision.

Re: BETTER Mitigation

[reanjr]

This doesn't even affect Debian systems.

Re:

[drinkypoo]

This doesn't even affect Debian systems.

*It doesn't affect Debian systems until you install systemd-coredump.

Per TFS, Debian issued an advisory.

There would be no need for them to do so if Debian systems were not affected.

QED, TL;DR: yes it does.

Re: BETTER Mitigation

[reanjr]

Yes, you can always configure your system to be broken. But if you choose not to, then the fact Debian uses systemd doesn't open you up. So, no, choosing not to use systems does not change anything.

You could install systemd-coredump on a system that doesn't use systems.

Re:

[gweihir]

Installing an entirely legitimate package is not "configuring your system to be broken". Your position is stupid and indefensible.

Re:

[oldosadmin]

Non-systemd Debian and more and more Devuan here. This is not a high criticality vulnerability, but, after the sshd near-disaster, the second time not running systemd proves to be the right decision.

I can't hear "Debian" and "sshd" and "disaster" in the same sentence without thinking of https://research.swtch.com/ope... [swtch.com] (the OpenSSL bug from September 2006). It really took me a minute to realize you were talking about the xz-utils attack.

Re:

[gweihir]

Hahaha, sorry. I should have been more clear. Yes, I meant the recent backdoored liblzma being pulled into OpenSSH sshd via some stupid libsystemd patch made by several terminally incompetent Linux distro maintainers. Altough the 2006 screw-up by that Debian wannabe maintainer was pretty spectacular. Such a stupid beginner's mistake! Noth that the xz-utils disaster was much better.

I guess the learning is that stupid people exist in the Linux space as well, and some are distro maintainers. One reason I am us

Re:

[Lady Galadriel]

How dare you! I am offended, I tell you highly offended! You should weep with the misery you have caused!

Everyone KNOWS their are other Distros that don't include the malware SystemD!
Slackware and Devuan are not the only ones!

I know, because I use the far superior Gentoo.
(Okay, it's not "far" superior. And maybe not even superior... Fine, I'll admit it, Gentoo is a right pain in the butt at times.)

Re:BETTER Mitigation

[OrangeTide]

But it's the butt pain you willingly accepted. Unlike systemd. I mean really, did any end-user agree to "let's use journalctl for accessing all the logs, and ONLY use journalctl".

Re:

[caseih]

I've been using Fedora for years, along with RHEL, and I still have rsyslog on Fedora, and I refer to /var/log/messages all the time. Journal has more details and granularity, though.

Re:

[vbdasc]

The only thing that is superior in Gentoo over Devuan is its cool penguin. But hey, everyone is entitled to their own opinion :)

Re: BETTER Mitigation

[drinkypoo]

I would say that making it relatively easy to build the system with your desired options is superior. I don't think any other part of the system is though, which is why I don't run it any more.

Re: BETTER Mitigation

[rthille]

FreeRTOS?

Re:

[jmccue]

I use Slackware and only used Slackware for personal use, at work I had a RHEL Workstation until I left.

I know Slackware does not create core files by default, I had to enable that for my ID for development. At work I do not remember getting core dumps, but I never bothered looking.

So systemd-coredump will start creating core dumps all over the place ? There was a time not getting core dumps was annoying for me due to the way *BSD and other UNIXs work, but I got use to it adapted ages ago. Now you get co

In order to successfully carry out the exploit :o

[Mirnotoriety]

“In order to successfully carry out the exploit, an attacker must have permissions to create user, mount and pid namespaces with full capabilities.”

Re:

[93 Escort Wagon]

Sigh... chaining exploits together is a thing, and it happens in the real world. Quite a bit.

It raises the difficulty of pulling off this sort of exploit, but it doesn't prevent it.

Re: In order to successfully carry out the exploit

[reanjr]

So they have to essentially have root access.

Yeah, come at me bro. Bring on the attack.

Re:

[drinkypoo]

So they have to essentially have root access.

I thought the same thing, but then I thought about it some more. They could instead only have access to a container where a daemon which uses *pwent functions runs. It has its own namespaces.

Re:

[luther349]

then if your running immutable linux well big deal even if they did they cant change or hurt the system.

Curious

[ArchieBunker]

Why is a program designed to sequence things during the boot process involved with core dumps?

Re:

[OrangeTide]

Someone brought the Microsoft way of thinking into the Linux world.

Re:

[tlhIngan]

Why is a program designed to sequence things during the boot process involved with core dumps?

It's not. Systemd is a collection of core system utilities that interface between the kernel and userspace. init functionality is but one part of the package, there are others including system logging, crash dump analysis, DNS resolver maintenance, etc. It's a collection of utilities and most of them are broken out in most distributions so you can replace individual pieces as desired.

Ubuntu, for example, doesn't us

Re: Curious

[drinkypoo]

"It's a collection of utilities and most of them are broken out in most distributions"

You had me at broken

Re:

[caseih]

It's definitely not. Apport is an Ubuntu-specific daemon. Nothing to do with systemd init, which is also present on Ubuntu.

Systemd is a collection of optional, low-level components for building Linux distros. coredump is one of these optional services which you can disable or remove as you'd like. It's not part of the systemd init system and has nothing to do with sequencing boot items.

I know you already know all this, but spreading FUD about systemd is so popular that I feel the need to set the record

containers and namespaces

[OrangeTide]

who knew this would be so full of holes

Induce a crash?

[spitzak]

Seems to me that "if a local attacker manages to induce a crash in a privileged process" indicates a security problem, not that you can do something with the resulting crash dump.

systemd

[fluffernutter]

Seriously, has anyone except OS developers ever found systemd an improvement to init.d in any way as opposed to something that you have to fight with harder?

Re: systemd

[reanjr]

Yeah. SysVInit was trash. Every body doing their own bespoke implementations of really basic shit and opening you up to these sorts of attacks in the form of bash scripts with full command over the system.

As an admin who was responsible for setting up custom daemons, systemd made my life way easier, the daemons was more stable, and modularization was possible in a way SysVInit couldn't even begin to offer.

Re:

[fluffernutter]

The daemons aren't more stable. Systemd is just hiding it by restarting them. And how can you have a problem with permissions conflicts on shell scripts? If you don't know how to set permissions on a shell script that runs with privileges then that's the problem.

Re:

[reanjr]

I actually use systemd, which I'm guessing you have very limited experience with. Auto restart isn't even enabled by default. If it's auto-restarting, that's something I did, not systemd.

SysVInit scripts are run as root. And then you have to remove privileges. Systemd services run without access to anything. Then you have to add privileges.

And then auditing. Oh my God, auditing a SysVInit script and tracking the execution model scattered across half a dozen utility scripts, (some with setuid bit!), th

Re:

[drinkypoo]

And then auditing. Oh my God, auditing a SysVInit script and tracking the execution model scattered across half a dozen utility scripts, (some with setuid bit!), then trying to cobble all that together into a cogent security model? Ridiculous.

Not nearly as ridiculous as trying to troubleshoot a boot problem caused by systemd which occurs before its bullshit logging eventually begins, which has to be done with a debugger.

Re:

[caseih]

Yes I have. Creating daemons is super simple now as is process supervision. I hated hacking init scipts and not everyone followed the same recipe (qmail was one I recall). Lots of wheels being reinvented, lots of broken methods of doing process monitoring. Heck the actual unix operating systems I used to use had all abandoned pure borne shell hacky init scripts years ago (HPUX, Solaris, even macOS). Lots of third-party solutions were proposed over the years including supervisord, which was quite slow.

Re:

[The-Ixian]

For most people, it's a lot easier to create a configuration file with simple, straightforward directives in a directory than it is to create your own init script, that's for sure.

System D feels similar to Windows Services. It's relatively simple to understand and start using, but there is a lot of nuance for different use cases. Whereas init scripts always felt very..... rigid, I guess.

Re:

[drinkypoo]

I wrote a long reply and then Slashdot's stupid fuck filter blocked me from posting it, so in protest this is all I'm going to write here.

Re:

[aRTeeNLCH]

As someone who's been bitten by the same thing, I'd like to say your long message made total sense and it would have set straight and convinced the staunchest unbelievers, in fact, it's quite possibly the one piece of prose that could have fixed antivaxxers, trumptard MAGAists as well as climate deniers. Alas, because of Slashdot filters it got lost in cyberspace, and so the suffering continues....