A week after Copy Fail, researcher Hyunwoo Kim disclosed a second Linux kernel flaw in the same broad area — IPsec ESP and rxrpc — that they have named Dirty Frag. The bug lives in the in-place decryption fast paths of esp4, esp6, and rxrpc: when a socket buffer carries paged fragments that are not privately owned by the kernel (e.g. pipe pages attached via splice(2)/sendfile(2)/MSG_SPLICE_PAGES), the receive path decrypts directly over those externally-backed pages, exposing or corrupting plaintext that an unprivileged process still holds a reference to.
Like the previous Copy Fail vulnerability, Dirty Frag immediately yields root on all major distributions. Every supported Manjaro release is affected. Dirty Frag chains two distinct kernel bugs, each with its own CVE: CVE-2026-43284 covers the IPsec ESP half (esp4 / esp6), and CVE-2026-43500 (NVD entry pending) covers the rxrpc half. Per Hyunwoo Kim’s public disclosure on oss-security (2026-05-07), the responsible-disclosure embargo was broken before distributions could coordinate, and a working exploit is publicly available. A second public exploit, Copy Fail 2: Electric Boogaloo, targets the same vulnerability under a different name; both reach root through the same esp4/esp6/rxrpc code paths and are blocked by the same fix.
You can neutralize the attack surface by blacklisting the affected modules. None of esp4, esp6, or rxrpc are loaded on a typical workload that does not use IPsec transport mode or AFS, so on most systems this is safe to apply immediately:
This writes a modprobe config that prevents the three modules from loading, and unloads them if they happen to be loaded already (the rmmod is best-effort and silent if the module isn’t present). To revert, remove /etc/modprobe.d/dirtyfrag.conf.
The Dirty Frag exploit works by corrupting page-cache pages of sensitive files (such as /etc/passwd or /usr/bin/su). If you suspect the system may have already been targeted before you applied the mitigation, drop the page cache so any tampered pages are evicted and the next read comes fresh from disk:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
This is safe to run on a live system — it only frees clean cache and dentry/inode entries — and pairs well with the blacklist above.
Upcoming Fixes
We are currently building some kernels with early patches applied:
Upstream released 6.6.138, 6.12.87, 6.18.28 and 7.0.5 to fix the first part of the vulnerability in ESP modules … Kernels are currently building on our end on Github CI.
thanks for your fast action @philm ! unfortunally this part of the kernel will cause many more issues in the upcoming days and weeks, so stay alerted. copy-fail was just a first climpse of the problem that was detected via this ai-slop. dirty-frag is a deeper examination that shows up much more intrusion-bugs related to copy-fail but it seems that the whole mechanism isn’t safe.
Buen dia, pregunta, es necesario escribir la sentencia que fue enviada para mitigar el efecto de Dirty Frag o es solo para servidores, empresas, etc.?
Muchas gracias
English translation:
Good morning, question, is it necessary to write the sentence that was sent to mitigate the effect of
Dirty Frag or is it only for servers, companies, etc.?
Thank you so much
It allows everybody that runs as a user on your system, including programs (!), to become root!
My recommendation is: Yes, apply the Temporary Mitigation to every system that you plan to use until the Kernel Updates are available unless you take the utmost care that nothing potentially exploiting it is coming onto your system!
Thanks for the update and for the quick work on getting these kernels built! Since this is my first post here, I wanted to say hello and also ask: will there be a follow-up post in this thread once the fixes are available in the repositories?
Well, it is super simple. This issue is complex and even upstream can’t provide a proper fix for this yet. Kernels are complex by nature. And with AI a lot of stuff can be done faster than before. Hence, the issue was so long undetected but present for several years. So if you have a Linux-box and internet enabled and know about this, well you can become root on any machine by opening the console and download the exploit with a one-liner.
Since this is in the public already, I try to cover it from our end as needed. The first post gets updated on a regular basis.
To be save, apply the mitigation. If you want to help: switch to unstable branch and keep updating your system and give feedback.
You can be sure that a lot of kernel updates will follow the upcoming days …
well running a server with manjaro-unstable sounds stupid but it works !!! thanks @philm . i wish debian would act as fast as you cause i’m lost that debian-support isn’t delivering so quick. credits to manjaro
For what it’s worth, I was speaking with a friend last night who uses LMDE. It seems the kernels are being patched, but maybe not quite as fast as we’re getting used to being the case here.
Naturally, thanks @philm for these efforts. It is really appreciated.
i’m curious about the different sources on which kernels are already patched, especially about the kernel 6.12… phil’s list point out that only 6.12.87 is patched while debian’s sources declare 6.12.86 (which they are using now) as patched. i have no clue what kernel to use when everyone submits different opinions.
These AI discovered exploits are only strengthening Linux Kernel ultimately… I think this will be a temporary phase we go through as white hat security researchers catch up with AI tools.
Hoping no such embargo breakages happen again and are handled like Copy Fail (the first one), which I am sure will be precautions in place to avoid such incidents, I understand it’s hard to avoid because of GPL rules… Surely there will be a way to handle it.
Ultimately this is much better than closed source OS, who knows what kind of backdoors are in place on those systems…
