Dirty Frag: Universal Linux LPE

zed · May 7

As with the previous Copy Fail vulnerability, Dirty Frag likewise allows
immediate root privilege escalation on all major distributions.

For detailed technical information about the vulnerabilities and the reason the
embargo was broken, please check https://dirtyfrag.io.

https://openwall.com/lists/oss-security/2026/05/07/10

REDACTED [Libera] -!- WALLOP amdj: [Network Notice] Linux system administrators should beware of another local privilege escalation vulnerability that recently dropped (CVE number not yet assigned): https://github.com/V4bel/dirtyfrag/blob/master/README.md

edit: redacted timestamp to keep my timezone secure!!

rdes · May 7

I'm tired boss.

deafcon · May 7

It's every freaking day now.

MikeA · May 7

This one is worse than the previous imo.

davide · May 7

That my paranoia pays out can finally be publicly acknowledged by you all folks:

$ uname -r
3.16.0-6-amd64

$ ls /usr/bin/sudo
ls: cannot access '/usr/bin/sudo': No such file or directory

and no file on the filesystem uses extended attributes (ping requires root).

Neoon · May 7

At this rate, microLXC will be switching to kvm, yesterday.

glueckself · May 7

It goes very well with the Apache RCE (CVE-2026-23918)
TLDR: Running Apache? Instant root...

zed · May 7

lol we're doomed, switching all my vps to win7

oloke · May 7

@Neoon said:
At this rate, microLXC will be switching to kvm, yesterday.

Can't wait for microLXC to be acquired by microKVM and rebranded

Neoon · May 7

@oloke said:

@Neoon said:
At this rate, microLXC will be switching to kvm, yesterday.

Can't wait for microLXC to be acquired by microKVM and rebranded

Not gonna register another domain unless you pay for it.

ChrisMiller · May 7

I really should have filed for PTO.

glueckself · May 7

I wish I could take PTO from my self-hosted stuff.

JabJab · May 7

2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.

Who was this amazing person please!?

glueckself · May 7

If you're applying the mitigations, you need to reboot or drop caches (https://github.com/V4bel/dirtyfrag/issues/1)

glueckself · May 7

Oh, and the mitigation might kill your IPsec tunnel. I don't know much about IPsec, I have only one in my DN42 lab, but that didn't came up after mitigations + reboot.

dbadude · May 7

MAMA

MikeA · May 7

@dbadude said:
MAMA

mia?

slowservers · May 7

Thank you for posting!

The author didn't test on Debian 13, so I tested it (well, I probably would have anyway!) I removed the buggy module that copy.fail requires.

monero@localhost:~$ /var/tmp/dirtyfrag/exp
# id
uid=0(root) gid=0(root) groups=0(root)

Working there. I guess there's no fix other than a manual patch and recompile right now.

What another great day to be using OpenBSD on most systems!

glueckself · May 7

@slowservers said:
Working there. I guess there's no fix other than a manual patch and recompile right now.

esp{4,6} and rxrpc are modules on Debian 13, so the modprobe.d mitigation is still possible.

whynotlearn · May 7

Micro-VM's are really looking attractive to many of these issues.

Has anyone tried anything to see if something similar can work on android this time around?

DataRecovery · May 7

@MikeA said:

@dbadude said:
MAMA

mia?

Here we go again

forest · May 8

@zed said: edit: redacted timestamp to keep my timezone secure!!

But do you block CTCP TIME?

default · May 8

forest · May 8

@MikeA said:
This one is worse than the previous imo.

They're both actually really mild because the mitigation is so easy: blacklist the kernel modules. LPEs in Linux are common but usually don't get their own CVE published or a user-to-root PoC written. It would be a lot more scary if we started seeing trivial vulnerabilities in the core kernel in places that are hard to mitigate, like futex() or the core mm subsystem.

For the future, this is a good reminder to everyone to run sysctl -w kernel.modules_disabled=1 so modules won't be autoloaded. There are SO many kernel modules that will get autoloaded that bugs are always just waiting to be found.

zed · May 8

This is additional info regarding the "embargo break"
https://openwall.com/lists/oss-security/2026/05/07/12

At least one of the public artifacts in circulation — my "Copy Fail 2: Electric Boogaloo" repo — is an n-day built from the public netdev fix commit, not a break from inside the embargo.

Timeline on my end: - Steffen Klassert's fix landed publicly on netdev/net.git as commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4.

Brad Spengler (@spendergrsec) publicly called the commit copyfail-class. - I read the commit, recognized the xfrm ESP-in-UDP MSG_SPLICE_PAGES no-COW path against shared pipe pages as an LPE primitive, and built a PoC.

This shit happens live and in realtime in case you didn't realize!

From the email:
Copy_Fail2-Electric_Boogaloo Write-up:
https://afflicted.sh/blog/posts/copy-fail-2.html
https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4

MikeA · May 8

@forest said:

@MikeA said:
This one is worse than the previous imo.

They're both actually really mild because the mitigation is so easy: blacklist the kernel modules. LPEs in Linux are common but usually don't get their own CVE published or a user-to-root PoC written. It would be a lot more scary if we started seeing trivial vulnerabilities in the core kernel in places that are hard to mitigate, like futex() or the core mm subsystem.

For the future, this is a good reminder to everyone to run sysctl -w kernel.modules_disabled=1 so modules won't be autoloaded. There are SO many kernel modules that will get autoloaded that bugs are always just waiting to be found.

I agree, but the problem is the amount of hosts, especially web hosting providers, that can be 100% destroyed if their team isn't monitoring for these new exploits hourly 24/7. I contacted some people about this who had no idea about it, and could have been wiped.

forest · May 8

@MikeA said:

@forest said:

@MikeA said:
This one is worse than the previous imo.

They're both actually really mild because the mitigation is so easy: blacklist the kernel modules. LPEs in Linux are common but usually don't get their own CVE published or a user-to-root PoC written. It would be a lot more scary if we started seeing trivial vulnerabilities in the core kernel in places that are hard to mitigate, like futex() or the core mm subsystem.

For the future, this is a good reminder to everyone to run sysctl -w kernel.modules_disabled=1 so modules won't be autoloaded. There are SO many kernel modules that will get autoloaded that bugs are always just waiting to be found.

I agree, but the problem is the amount of hosts, especially web hosting providers, that can be 100% destroyed if their team isn't monitoring for these new exploits hourly 24/7. I contacted some people about this who had no idea about it, and could have been wiped.

Absolutely. It's quite a trivial privesc.

It's also yet another reason why containers suck as an isolation technology.

jfrac · May 8

VM escape 0-day when?

forest · May 8

@jfrac said:
VM escape 0-day when?

They happen but severe vulnerabilities in the host kernel part of the hypervisor are relatively rare (except for in Xen lol) considering its much smaller attack surface area. Most exploitable vulnerabilities are in the userspace components, e.g. QEMU, which are easier to mitigate with sandboxing.

ScreenReader · May 8

there has to be a way to blacklist all unused modules if the vps are just being used for a wireguard tunnel, ping probe or something, anyone ever made this kind of list?

i'm not being a skitzo here but it's just inane if there's a weekly easy-to-exploit vuln just because some module in lunix kernel is enabled and i never uses it in the first place. i'm losing billions of dollah here every 1 min applying a mitigation and doing one reboot in every chicken. someone has to stop this!

forest · May 8

@ScreenReader said: there has to be a way to blacklist all unused modules if the vps are just being used for a wireguard tunnel, ping probe or something, anyone ever made this kind of list?

sysctl -w kernel.modules_disabled=1

That will prevent loading and unloading of new modules that aren't already loaded.

Howdy, Stranger!

Categories

In this Discussion

Dirty Frag: Universal Linux LPE

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Dirty Frag: Universal Linux LPE

Comments