Fragnesia Made Public as Latest Linux Local Privilege Escalation Vulnerability | Hacker News Reader

Fragnesia Made Public as Latest Linux Local Privilege Escalation Vulnerability

phoronix.com

44 pointsmikece19 comments

The primary source, which says keep the dirtyfrag mitigations in place, is https://github.com/v12-security/pocs/tree/main/fragnesia

Lots of privilege escalations these days. But are there that many multiuser Linux systems nowadays ? I'm under the impression the whole landscape is either servers or single-user desktops (and ofc Android phones).

The idea is that you can exploit a service hosted on Linux to run these.

I impersonate multiple users on my machine for organizational reasons.

LPEs also potentially make user-level malware into system-level malware, which is only marginally more impactful for a single person on a desktop, but considerably harder to clean up. (It also broadens the range of what such malware could exfiltrate from me.)

> many multiuser Linux systems nowadays

not relevant IMHO

we don't live anymore in a time where you can trust that local apps do not misbehave, and in such a context LPE is pretty bad even in a single user system

just thing about all the supply chain problems of recent times

I would say that in a single-user system LPE isn't even needed. The moment you run malicious code all bets are off. No need to compromise the system when all your data is under "enemy" control.

Technically, running malicious code doesn't necessarily give control over all your data in the device. But common Linux is still lacking in sandboxing practicality, so it might as well be that way.

You might not have root on an organizational "managed" system.

Many university HPC clusters are run multiuser. At least login nodes.

Any university or national HPC system as I'd understand the term is multi-user.

There are also things like the extensive high energy physics WLCG compute federation, which is somewhat different, but can potentially be compromised quickly at large scale. For the original copy-fail we didn't want to drain our WLCG Alma9 cluster, or just kill all the jobs like the university HPC system. We got eBPF mitigation in place within a couple of hours, relieved the exploit signature wasn't in logs from the night before. That would have been done earlier if Proofpoint hadn't bounced the forwarded oss-security article as "contains malware"; sigh.

Yes, lots of little web services and such run as unprivileged users, not root. I personally run a bunch of stuff as very restricted users in containers, with the threat model being that e.g. an RCE exploit in one of them will only affect the service, not the broader system.

At what point do we all start rolling our own microkernels? This is kind of getting silly now... 4 now in the past month?

I hate that the Qubes OS people were right.

Sounds like this one is in the same kernel modules as dirtyfrag, so the existing mitigations (if in place) are sufficient.

RedHat's mitigation is this:

  $ cat /etc/modprobe.d/dirtyfrag.conf
  install esp4 /bin/false
  install esp6 /bin/false
  install rxrpc /bin/false

Are those correct for this exploit?

https://access.redhat.com/security/vulnerabilities/RHSB-2026...

I don't know, but the problem with blocking esp4 and esp6 is that IPsec stops working, as I understand it.

For those who can I would recommend upgrading to Wireguard.

Yep, that's the advice from AWS for the previous set of vulnerabilities:

https://aws.amazon.com/security/security-bulletins/2026-027-...

That one also includes disabling user namespaces. Could be problematic if they're in use.

UnRAID has released two point upgrades in the past two weeks because the previous AI-found vulnerabilities. Here we go again!

Reply on news.ycombinator.com