Dirtyfrag: Universal Linux LPE

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.

"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"

    sudo echo 3 > /prox/sys/vm/drop_caches

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.]

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.

After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?

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

Ran as a fresh new default user in a ubuntu:latest container

  git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

  dirtyfrag: failed (rc=3)

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.

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?

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

Just got an email from one HPC I have access in Germany. I guess all HPCs ans services like GH Actions are going to be offline for a bit. I think last time was on a Friday too, so it might be another Friday to organize emails, files, rotate backup/passwords...

Disclosure Timeline

2026-04-29: Submitted detailed information about the rxrpc vulnerability and a weaponized exploit that achieves root privileges on Ubuntu to [email protected].

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.

Testing the rxrpc vuln on aarch64, I get a kernel data abort, which is interesting. Not looked into the root cause yet!

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

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

Tanenbaum was right

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?

this is why you don't contact distro mailing list. responsible disclosure is dead.

Anyone here with experience providing multi-tenant Linux systems (CI and the like), do providers usually disable kernel modules they don’t need to eliminate attack surface? Every time one of these comes out I wonder if I should be rotating every key in my GitHub CI or PaaS host. So far I haven’t seen any reports from the providers I use that they were pwned by any of these exploits.

can this also be used to obtain container escape ?

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

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?

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.

Here we go again

[dead]

[dead]

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

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.

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.