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"

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

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

Looks like the esp4 and esp6 fixes have been pushed for 7.0, 6.18, 6.12 and 6.6 kernels.

https://lore.kernel.org/lkml/2026050851-iron-hurdle-6421@gre...

https://lore.kernel.org/lkml/2026050843-unplowed-spinster-cf...

https://lore.kernel.org/lkml/2026050832-remold-faceless-bed0...

https://lore.kernel.org/lkml/2026050825-heaving-spender-13a8...

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?

There's, in practice, unlimited such bugs in the megabytes of kernel object code.

Monolithic UNIX-like kernels are a bankrupt design.

Only third generation microkernels like seL4[0] make sense in the present world. All effort put elsewhere is wasted outright.

0. https://sel4.systems/

I can't make it work on nixos. Kernel 7.0.1

I tried fixing the paths and even linking `/bin/bash` to the nix /run/current-system/sw/bin/bash

/etc/passwd is unmodified.

Can anyone else try? CopyFail1 did not work because `su` is only executable, not readable, CopyFail2 worked only partially (changes /etc/passwd but the user is not passwordless)

I'm not a security expert, but I'm responsible for some (relatively low-stakes) production systems.

It sounds like these two most recent exploits depend on unprivileged user namespaces, and that in fact a high percentage of LPE exploits need this feature. I use rootless containers on a couple of systems (like my dev machine server), but on most of my systems I don't, so it sounds like disabling that would be a good step to hardening my systems against future exploits.

To the security experts: are there any other straightforward configuration changes with such broad-reaching improvement in security posture? Any well-written guides on this subject, something like "top kernel modules to consider disabling if you don't need them"? I'm not talking about the obvious stuff like "disable password SSH", I'm specifically looking for steps that are statistically likely to prevent as-yet-unknown privilege escalation attacks.

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.

Both of these (copy fail and dirtyfrag) exploit obscure socket address families. Are these filtered by commonly used seccomp profiles in eg docker (assuming seccomp can express it)?

Perhaps we should consider designing distributions to be more tailored to specific purposes. Since no one needs the affected module on a desktop computer, distributions designed for that purpose should no longer include it by default. If this approach were consistently followed, significantly fewer systems would be vulnerable to such exploits. For most users a system with a kernel as minimalistic as the Android GKI kernel combined with sensible SELinux policies, would likely be sufficient.

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

Result:

  dirtyfrag: failed (rc=3)

Good news!

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

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.

We need an easy way to ensure that only kernel modules in an whitelist can load. I’m tired of blacklisting modules I never need.

Is there a CVE identifier available for this yet?

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?

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

Considering AWS just released patches for Copy Fail for Amazon Linux and Bottlerocket only yesterday.... I imagine it will over a week before we see patches for this. This is especially important to fix on Kubernetes nodes...does anyone have any recommendations for mitigating this issue before a patch is released?

The enforcement of read-only protection for pagecache pages (and the scatterlists and or other structures they point to) seems to be diffuse and incredibly fragile.

RxRPC is apparently an AFS (Andrew File System) thing.

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

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?

well at least they are not commonly loaded - in like 12 machines i have

From the 3rd party discloser:

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

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.

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.

can this also be used to obtain container escape ?

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?

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

Tanenbaum was right

Two distro independent LPEs in such a short time, if only all Linux software could be this portable.

Imagine how many undiscovered bugs and exploits exist in Windows.

[dead]

[dead]

[dead]

[dead]

[dead]

[flagged]

[flagged]

Here we go again

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.

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

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.

Where is the famous Linux is so much secure than Windows?

I would like to see the same hate comments about Linux than the ones we would see if it was a Windows vulnerability...