New Linux Vulnerabilities
They’re interesting:
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.
[…]
“This means that 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.”
Moderate severity, but definitely worth fixing.
Slashdot thread.
Subscribe to comments on this entry
Clive Robinson • June 3, 2025 11:35 AM
@ Bruce, ALL,
There has always been the question of code size –as well as complexity– against security.
Some parts of the GNU/Linux eco system are shall we put it,
“Way beyond the acceptable limits”
With regards to size and complexity and to give such parts the highest of “security access/control” is frankly unwise.
One such that has caused me concern for quite some time is “SystemD” and apparently I’m not alone in this.
There are several fundamental rules for designing secure systems perhaps the most important is,
“Segregation of function.”
With attendant,
“Strong oversight and minimum privilege.”
Further that you design the system in such a way that for each part,
“You clock the inputs and clock the outputs”
As not only does this knock various forms of “side channel” back it also makes “race conditions” like wise much less of a potential issue.
However with regards SystemD, there appears to be a perverse desire in it’s developer to,
“Extend to, and embrace all.”
To be the master of every thing and certainly way beyond what in all honesty is wise. As SystemD has become what is effectively an impenetrable conglomeration it breaks the basic Secure Design rules.
But it’s not just from a security perspective but also from one of a SysAdmin having to abdicate control to the whims of the developer.
I think it’s safe to say that even though this instance is a “moderate severity” issue… We are going to see increasing issues with SystemD
As I’ve noted in the past there is the issue of,
“Security v. Efficiency”
And whilst it is in manageable modules possible to have a degree of both, it’s usually not going to happen due to the way the industry works currently.
So with any code base like SystemD it would be unwise to assume that any new vulnerabilities are going to be “moderate”…