DirtyClone Lets a Local User Rewrite su in Memory to Get Root. The Fix Shipped in May, the Exploit Dropped Yesterday.

A security firm published a working exploit yesterday for a Linux kernel bug that lets any local user rewrite /usr/bin/su in memory and walk away with root. The file on disk never changes. The patch has been in the mainline kernel since May 21, so this is a "go check your kernel version" story, not a five-alarm fire. But the way the bug works is worth understanding, because it is the fourth time in two months the same mistake has produced a root exploit.

The bug is CVE-2026-43503. JFrog's security research team, Or Peles and Eddy Tsalolikhin, named their exploit DirtyClone and posted the walkthrough on June 25. It carries a CVSS score of 8.8 and it is a local privilege escalation, which means an attacker needs to already be on the machine with an account before any of this matters. No remote angle. Nobody is hitting your server with this from the open internet.

What the bug actually is

Modern Linux networking tries hard not to copy data it does not have to. When you send a file over a socket, the kernel can hand the network stack a pointer to the same physical memory page the file already lives in, instead of duplicating the bytes. That page sits in the page cache, the kernel's in-memory copy of file contents. The same physical page can therefore be two things at once: the cached copy of an executable on disk, and the payload of a network packet.

That is fine as long as nothing writes to the page while it is wearing its packet hat. To enforce that, the kernel sets a flag on the socket buffer, SKBFL_SHARED_FRAG, that means "this buffer points at shared, possibly file-backed memory, so copy it before you modify it." Any subsystem that does in-place work on a packet, IPsec decryption being the relevant one here, checks that flag and makes a private copy first.

DirtyClone exists because the flag gets dropped. When the kernel clones a socket buffer through __pskb_copy_fclone(), the clone does not inherit the shared-frag marking. The original buffer is still flagged correctly. The clone is not. Send the clone through an operation that writes in place, and the kernel writes straight into the file-backed page it was supposed to protect. As JFrog puts it, "the underlying attack primitive is not limited to a single vulnerable code path." The same flag can be lost in several places.

How you get from a dropped flag to root

The exploit is clever in a way that is worth spelling out once.

The attacker maps /usr/bin/su into memory, which pulls it into the page cache. Then they use vmsplice and splice to build a network packet whose payload points at that same page rather than copying it. They set up a loopback IPsec tunnel so the packet never leaves the machine, and add an iptables TEE rule, which duplicates the packet inside the kernel and triggers the vulnerable clone. The cloned buffer, now missing its safety flag, reaches the IPsec decryption stage.

IPsec decrypts in place for speed: the output overwrites the input buffer. Because the attacker controls the encryption key and the initialization vector, and because AES-CBC's output for a block depends on the IV, they can compute inputs that make the decrypted bytes come out to whatever they want. The decryption writes those chosen bytes into the page-cache copy of su, patching out the few instructions that check whether you are allowed to become root. The next time anyone runs su, the kernel serves the modified page from cache, and the authentication check is gone.

The part that makes it nasty

The disk file is never touched. The modification lives only in the kernel's in-memory copy. JFrog notes the attack "is silent, leaves no kernel logs or audit traces, and bypasses common on-disk integrity monitoring tools." A tool that hashes su on disk sees nothing wrong. A reboot flushes the page cache and restores the original binary, by which point the attacker has had root for as long as they needed it.

Who is actually exposed

Setting up the IPsec tunnel requires the CAP_NET_ADMIN capability. On a locked-down server, an ordinary user does not have it. The catch is unprivileged user namespaces, which let a normal user create a sandbox in which they hold capabilities like CAP_NET_ADMIN over the namespace's own networking. Whether that is exploitable comes down to distro defaults:

• Debian and Fedora ship with unprivileged user namespaces enabled, so a local user can pick up the capability inside a fresh namespace with a single unshare -Urn. Vulnerable by default.
• Ubuntu 24.04 and later restrict namespace creation through AppArmor, which blocks the default exploit path. Still listed as affected, because the restriction is a speed bump rather than a fix.

JFrog confirmed the exploit on Debian, Ubuntu, and Fedora systems running default namespace configurations. The systems that should care are the ones that hand shell access or container workloads to people you do not fully trust: multi-tenant servers, CI runners, container hosts, Kubernetes clusters. The page cache is shared across the whole host, so a change made from inside one namespace lands on every process on the machine, container boundaries included.

There is no evidence anyone is using this in the wild. It is a research proof of concept, and the fix predates the writeup by more than a month.

The fourth one since April

The reason to pay attention is not this one bug. It is the streak. DirtyClone is the fourth Linux privilege escalation since April built on the exact same failure: file-backed memory gets treated as packet data, and an in-place network operation writes where it should have copied.

Each fix closed the specific function it found and left the flag-dropping pattern alive somewhere else. The original DirtyFrag researcher, Hyunwoo Kim, submitted a broader patch on May 16 covering several more fragment-transfer helpers, and that combined fix is what shipped as CVE-2026-43503. The problem underneath all four is a contract that the kernel keeps failing to honor: every code path that moves socket-buffer fragments has to carry the shared-frag flag along with them, every single time, and zero-copy networking has a lot of those paths. Miss one, and a performance optimization turns into a write primitive. Expect a fifth.

What to do

Install your distribution's kernel update. The fix landed upstream in v7.1-rc5, merged May 21 and assigned its CVE on May 23, and has been backported to the stable and LTS branches. Ubuntu (USN-8373-1), Debian, and SUSE have published advisories, and Red Hat has a Bugzilla tracking entry.

If you cannot patch immediately, there are two stopgaps, both with side effects. Setting kernel.unprivileged_userns_clone=0 blocks the namespace trick that hands out CAP_NET_ADMIN, at the cost of breaking anything that legitimately uses unprivileged namespaces. Blacklisting the esp4, esp6, and rxrpc modules removes the in-place decryption primitive, but breaks IPsec and AFS and only works if those features are built as modules rather than compiled into the kernel. Both are controls to buy time, not replacements for the patch.