Dirtyfrag: Universal Linux LPE

baggy_trough

Disclosure Timeline 2026-04-29: Submitted detailed information about the rxrpc vulnerability and a weaponized exploit that achieves root privileges on Ubuntu to security@kernel.org. 2026-04-29: Submitted the patch for the rxrpc vulnerability to the netdev mailing list. Information about this issue was published publicly. 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly. 2026-05-07: Detailed information and the exploit for the esp vulnerability were published publicly by an unrelated third party, breaking the embargo. 2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.

john_strinlai

"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities." link: https://github.com/V4bel/dirtyfrag detailed writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... importantly: " Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is triggered regardless of whether the algif_aead module is available. In other words, even on systems where the publicly known Copy Fail mitigation (algif_aead blacklist) is applied, your Linux is still vulnerable to Dirty Frag. " mitigation (i have not tested or verified!): " Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. Use the following command to remove the modules in which the vulnerabilities occur. " sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true" conversation around the mitigation suggests you need a reboot or run this after the above on already-exploited machines: sudo echo 3 > /prox/sys/vm/drop_caches

Tiberium

Do you think with modern LLMs in a few years projects like Linux will have all those low-hanging security bugs fixed? Are we witnessing a transition period, or will nothing change?

miduil

This again does not work under Android, at least in termux compiled with clang/gcc.

BadBadJellyBean

Well this is getting tiresome. I wish there was a less stressful way to get fixes for such bugs. But the cat is out of the bag now. Not criticizing whoever found the bug, of course.

unethical_ban

Here's a general question, are these vulnerabilities hitting Linux more than BSDs due to hit being a larger target or because its architecture is less secure by design?

int0x29

I'm curious what broke the embargo. Did it leak or did a third party find it independently?

oncallthrow

can this also be used to obtain container escape ?

firer

This is very similar in root cause and exploitation to Copy Fail. Which illustrates pretty well something that's lost when relying heavily on LLMs to do work for you: exploration. I find that doing vulnerability research using AI really hinders my creativity. When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. It's like a genie - you get exactly what you asked for and nothing more. The researcher who discovered Copy Fail relied heavily on AI after noticing something fishy. If he had to manually wade through lots of code by himself, he would have many more chances to spot these twin bugs. At the same time, I'm pretty sure that by using slightly less directed prompting, a frontier LLM would found these bugs for him too. It's a very unusual case of negative synergy, where working together hurt performance.

normie3000

So umm... should I rush home and turn off all my computers?

eqvinox

And I ask again: why the f*ck is algif_aead getting all the flak for copy.fail? It's authencesn being stupid. authencesn didn't get fixed. Now we got the results of that, turns out you can access the same (I believe) out of bounds write through plain network sockets. I wish I thought of that, but I didn't. [ed.: I'm referring to the through-ESP issue. The RxRPC one is AIUI completely unrelated.]

xxpor

Linux is a single user system and should be treated as such. Run your services as root. Don't rely on unix user primitives for security.

zepearl

So if I understand correctly 3 modules are involved: - esp4 (kernel config "CONFIG_AF_RXRPC") - esp6 (kernel config "CONFIG_INET_ESP") - rxrpc (kernel config "CONFIG_INET6_ESP") Is this correct?

ftheplan9

Was the embargo ACTUALLY broken or is somebody just looking for attention?

arian_

Every time someone finds a universal Linux privilege escalation, somewhere a sysadmin whispers 'this is why we don't run as root' while nervously checking if their containers are actually isolated.

KamiNuvini

Does anyone know whether Debian is vulnerable? I tried the exploit on a Debian 12+Debian 13 machine but wasn't able to reproduce it myself.

chromacity

If this indeed works on all major distributions, I just continue to be amazed by how irresponsible the maintainers are. We're talking about optional kernel functionality that's presumably useful to something like <0.1% of their userbase, but is enabled by default?... why? This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet. Except it's not 1999 anymore.

eqvinox

If you don't need it (rootless containers), you can disable unprivileged userns to block these two: echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns May also break sandboxes (e.g. browser) though.

acedTrex

Here we go again

jcims

Tested Amazon Linux 2023 and it doesn't appear to be vulnerable in the default configuration. Would be interested if anyone finds anything different.