Dirty Frag Gives Root Access on Every Major Linux Distribution

A new Linux zero-day called Dirty Frag gives any local user full root access on every major Linux distribution, and right now no distribution has a patched kernel available. The researcher planned to give distributions until May 12 to prepare. Someone leaked the exploit five days early, and it went public before a single distribution had a fix ready.

Hyunwoo Kim (@v4bel) found both vulnerabilities and quietly reported them to the Linux kernel security team at the end of April, including working exploits and patches. The plan was to give Linux distributions until May 12 to prepare fixes before anything went public. On May 7, he told the group of distribution maintainers about it and set that five-day hold in motion. That same day, someone else published the exploit online. The agreement was clear: if that happened, everything would go public immediately. Kim released the full details within hours. Two CVEs have since been assigned: CVE-2026-43284 for the IPsec variant, which now has a patch in the kernel mainline, and CVE-2026-43500 for the RxRPC variant, which has no patch anywhere yet. How the exploit got out early is still unknown. The patch for the IPsec bug had been sitting on a public kernel mailing list since April 30, so someone paying close attention to kernel development could have spotted it there. Or someone inside the distribution group leaked it. Nobody knows.

For everyone who followed Kim’s previous discovery, Copy Fail (CVE-2026-31431), and applied the recommended mitigation: blocking the algif_aead module does not protect against this one. Dirty Frag takes a completely different path through the kernel, and the two mitigations do not overlap.

To understand what Dirty Frag does, it helps to understand how Linux handles files in memory. When a program reads a file, the kernel does not hit the storage device on every single access. It keeps a copy of recently-read files in RAM, in a structure called the page cache. That in-memory copy is what programs actually read. The file on disk stays untouched.

Dirty Frag exploits a path where the kernel can be made to write directly into those page cache pages on behalf of a user who only has read access to the file. Once the in-memory copy is modified, every program that opens that file sees the modified version. File integrity tools like Tripwire compare checksums on disk. Inotify watches for filesystem events. Neither one catches a write that only happens in RAM. From the perspective of standard monitoring software, nothing happened.

The mechanism involves a Linux system call called splice(), which is designed to move file data around the system as fast as possible. Instead of making a copy of the data, it hands the original memory pages directly to whatever is receiving them. That is what makes it fast, and that is exactly what Dirty Frag abuses. It uses splice() to plant a page from a read-only file directly into a network socket buffer, then triggers kernel code that performs encryption operations on that buffer without making a private copy first. The kernel ends up writing directly into the original file’s page, memory it was never supposed to touch.

Dirty Frag is actually two separate kernel vulnerabilities chained together. Each one covers the gap the other leaves behind.

The first vulnerability lives in the IPsec code. IPsec is the set of protocols the Linux kernel uses to encrypt and authenticate network traffic at the routing level, the technology running underneath most VPNs. The function that processes incoming encrypted packets is called esp_input(). Normally, before doing anything with incoming data, it makes a private working copy of whatever arrived. But there is a shortcut in the code: if the incoming packet has data fragments but no fragment list, it skips that copy step and works directly on whatever is sitting there. If splice() has already planted a page from /usr/bin/su or /etc/passwd into that packet, the kernel runs its operations directly on that file’s page in memory. The page gets modified. This bug has been in the kernel since January 2017. This variant requires the ability to create an unprivileged user namespace, which Ubuntu sometimes blocks through an AppArmor policy, so on those systems this path does not work.

The second vulnerability lives in RxRPC, a network protocol originally built for the Andrew File System, a distributed filesystem from the 1980s. Most systems no longer use it actively, but the kernel module loads automatically on Ubuntu. RxRPC has a function called rxkad_verify_packet_1() that verifies incoming packets by running a small decryption directly on the data that arrived. The problem is that it does not check whether the memory it is writing into actually belongs to the kernel. If that data came in through splice() from a file the attacker can read, the decryption overwrites the file’s page in memory directly. This bug was introduced in June 2023. Same root problem as the IPsec variant, completely different code path, and this one requires no user namespaces at all.

The IPsec variant works on most distributions but fails on Ubuntu when namespaces are blocked. The RxRPC variant works on Ubuntu because rxrpc.ko loads by default there, but does not work on RHEL because that module is not shipped. The two blind spots cancel each other out, and a single exploit binary handles both automatically. If the first path fails, it falls back to the second. The result is one binary that achieves root on all major Linux distributions.

The IPsec variant targets /usr/bin/su, the standard Linux utility for switching users. On Linux, certain executables can be marked to always run with the permissions of their owner regardless of who launches them. This is called the setuid bit. Because /usr/bin/su is owned by root and carries that bit, any program that replaces its in-memory code runs with root privileges. The exploit overwrites the first 192 bytes of the file’s page cache with a minimal root shell program using 48 separate four-byte writes. Running su afterwards drops straight into /bin/sh as root, bypassing the login flow entirely.

The RxRPC variant targets /etc/passwd, the file that stores user account information including the password field for each user. The exploit rewrites the root account’s entry so that the password field becomes empty. Linux uses a pluggable authentication system called PAM to handle logins, and one of its default settings called nullok accepts an empty password as valid. Once that modification is in place, running su - produces a root shell without a password prompt. This is what that looks like in the file:

1
2

root:x:0:0:root:/root:/bin/bash      ← original
root::0:0:GGGGGG:/root:/bin/bash     ← after the attack (empty password, garbage in GECOS field)

Both paths are deterministic. The exploit does not rely on timing tricks or race conditions, and it does not crash the kernel on a failed attempt. It either works cleanly or it does not run at all.

Here is what to check and do right now. First, check which kernel version is running:

1

uname -r

Then check whether the vulnerable modules are currently loaded:

1

lsmod | grep -E 'esp4|esp6|rxrpc'

If any of those appear in the output, the system is potentially vulnerable. The immediate mitigation from the researcher is to blacklist and unload them:

1

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; echo 3 > /proc/sys/vm/drop_caches; true"

Removing esp4 and esp6 disables IPsec on the system, so any VPN running on IPsec will stop working. Check that before applying it.

CVE-2026-43284 covers the IPsec bug, and its patch was merged into the kernel mainline on May 7. CVE-2026-43500 covers the RxRPC bug, and no patch exists for it anywhere yet. Neither fix has reached any Linux distribution kernel. Red Hat, AlmaLinux and CloudLinux are all working on backports, and KernelCare is preparing livepatches for systems that cannot reboot. Apply the module blacklist now and update the kernel as soon as a patched version lands.

The same class of kernel bug has now produced three separate exploitable vulnerabilities. The IPsec code has been carrying this flaw since January 2017. The RxRPC bug was introduced in June 2023. And nobody noticed either one until now.

Everything behind this, from privilege escalation and post-exploitation to persistence and understanding how real-world kernel attacks actually work, is covered step by step in my ethical hacking course:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: V4bel/dirtyfrag · oss-security disclosure · Red Hat RHSB-2026-003