How Dirty Frag Works
Dirty Frag is a Linux local privilege escalation exploit that chains two kernel vulnerabilities to get root on most major Linux distributions. It belongs to the same bug class as Dirty Pipe and abuses the page cache, which is how the kernel caches file data in memory.
The core trick is corrupting the frag member of a kernel struct sk_buff (socket buffer) in a way that lets an unprivileged user write to pages they should not be able to touch. Because the page cache is shared, this means you can overwrite read-only files including things like /etc/passwd or setuid binaries.
It chains two separate vulnerabilities to cover each other’s blind spots:
xfrm-ESP Page-Cache Write (CVE-2026-43284) requires permission to create a user namespace, which most distros allow by default. Blocked on some Ubuntu configurations by AppArmor. This vulnerability has existed in the kernel since 2017, giving it roughly a 9 year window of exposure. A mainline patch exists at f4c50a4034e6 but has not been backported to all distributions yet.
RxRPC Page-Cache Write (CVE-2026-43500) does not need namespace privileges, but requires the rxrpc kernel module, which Ubuntu loads by default but most other distros do not ship. No patch exists in any tree yet.
Together they cover nearly every major distribution. It is also deterministic, meaning no race condition, no kernel panic on failure, and a very high success rate.
The full technical writeup and proof of concept are available here: GitHub - V4bel/dirtyfrag · GitHub
Watch your distro’s security advisories for kernel updates. Links to known advisories are at the bottom of this post.
Mitigation
Before running anything in this post, read the impact table. The mitigation disables kernel modules and if you are running IPsec VPNs it will break them. When in doubt, test on a non-critical system first.
Also yes, I used AI to help write and research this one. I reviewed it for accuracy but as always with security stuff, cross-reference with your distro’s official advisories before acting on anything.
Until your distro ships a patched kernel, the best option is to blacklist and unload the vulnerable modules. AWS’s advisory extends the standard module list to also include ipcomp4 and ipcomp6, which sit in the same xfrm subsystem. This extended command is the most complete mitigation currently available:
bash
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\ninstall ipcomp4 /bin/false\ninstall ipcomp6 /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc ipcomp4 ipcomp6 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
What this does:
- Creates a modprobe rule that permanently blocks those modules from loading on boot
- Immediately unloads them if they are currently active
- Clears the page cache to flush any contamination
Verify the mitigation worked:
bash
lsmod | grep -E 'esp4|esp6|ipcomp4|ipcomp6|rxrpc'
# Should return nothing
Check if you are actively using IPsec ESP before running the mitigation, as it will break IPsec VPN connections:
bash
ip xfrm state
# If this returns active entries, you have live IPsec ESP sessions
If you cannot unload the ESP modules because you are actively using IPsec, you have two additional partial mitigation options from the AWS advisory.
Block unprivileged user namespace creation, which closes the xfrm-ESP attack path specifically (does not cover the rxrpc path):
bash
sysctl -w user.max_user_namespaces=0
If the vulnerable modules are not currently loaded at all, you can also disable all further module loading until next reboot:
bash
sysctl -w kernel.modules_disabled=1
Once your distro ships a patched kernel and you have updated, remove the blacklist to restore normal module behavior:
bash
rm /etc/modprobe.d/dirtyfrag.conf
Impact of the Mitigation
The drop_caches step flushes the page cache, dentries, and inodes. It is safe but causes a temporary performance impact as the cache warms back up. On a busy database or file server, avoid running this during peak hours. It does not cause data loss.
The modprobe blacklist persists across reboots, which is intentional. Remember to remove it after patching or the modules will remain disabled even on a patched kernel.
| Who you are | Impact of mitigation |
|---|---|
| Home desktop user | Virtually none |
| Self-hosted server, no IPsec | Virtually none |
| Running WireGuard or OpenVPN | None |
| Running IPsec VPN | VPN will break, use partial mitigation options instead |
| Using IPsec with compression | ipcomp4/ipcomp6 blacklist will also break compression |
| Using AFS file system | AFS will break |
| Busy production server | Run drop_caches off-peak |
| Docker host (unprivileged containers) | Apply at host level, containers are covered |
Distro Advisories
- Ubuntu / Canonical: Dirty Frag Linux kernel local privilege escalation vulnerability mitigations | Ubuntu
- Red Hat / RHEL: RHSB-2026-003 Networking subsystem Privilege Escalation - Linux Kernel (Dirty Frag) - (CVE-2026-43284) | Red Hat Customer Portal
- AlmaLinux: AlmaLinux OS - Forever-Free Enterprise-Grade Operating System (patched kernels already in testing repo)
- CloudLinux: Dirty Frag (CVE-2026-43284, CVE-2026-43500): Mitigation and Kernel Update on CloudLinux (KernelCare livepatches available)
- AWS / Amazon Linux: Dirty Frag and other issues in Amazon Linux kernels
–
Sources Referenced in video
Openwal Security Discussion
Copy fail 2: electric boogaloo
