DirtyClone is a new Linux kernel privilege escalation in the DirtyFrag family. JFrog Security Research published a working exploit walkthrough for the flaw on June 25, the first public demonstration for this variant.

Tracked as CVE-2026-43503 (CVSS 8.8), it lets a local user corrupt file-backed memory through a cloned network packet and gain root. The patch landed in mainline on May 21; if your kernel does not have it, update now.

When the kernel copies a network packet internally, two helper functions drop a safety flag that marks the packet's memory as shared with a file on disk. That missing flag is the entire vulnerability.

The attacker loads a privileged binary like /usr/bin/su into memory, wires those memory pages into a network packet, and forces the kernel to clone it. The cloned packet passes through an IPsec tunnel that the attacker controls, and the decryption step overwrites the binary's login checks with attacker-chosen bytes. The next time anyone runs su, it hands over root.

The file on disk never changes. The modification lives only in the kernel's in-memory copy, so file-integrity tools miss it, the attack leaves no audit trail, and a reboot restores the original binary. The attacker already has root by the time anyone might think to check.

Exploitation requires CAP_NET_ADMIN to configure the loopback IPsec tunnel. On Debian and Fedora, unprivileged user namespaces are enabled by default, so a local user can obtain that capability inside a new namespace.

Ubuntu 24.04 and later restrict namespace creation via AppArmor, blocking the default exploit path. Page cache is shared at the host level, so modifications made inside a namespace affect every process on the machine.

The exposed systems are multi-tenant servers, CI runners, container hosts, and Kubernetes clusters where untrusted users can create namespaces. JFrog confirmed the exploit on Debian, Ubuntu, and Fedora systems with default namespace configurations.

Fourth in a Series

This is the fourth recent privilege escalation with the same failure mode: file-backed memory gets treated as packet data, then an in-place network operation writes where it should have copied.

• Copy Fail (CVE-2026-31431) came first in late April, exploiting the algif_aead module for a four-byte page-cache write.
• DirtyFrag (CVE-2026-43284 and CVE-2026-43500) followed on May 7, chaining IPsec ESP and RxRPC paths for a full write primitive.
• Fragnesia (CVE-2026-46300) appeared on May 13, bypassing the DirtyFrag patch through a flag-dropping bug in skb_try_coalesce().

Each fix closed one code path and left others open. DirtyClone's demonstrated exploit centers on __pskb_copy_fclone(), with skb_shift() also affected; the broader CVE fix covers additional frag-transfer helpers where the same flag could be lost.

The underlying problem is not one bad helper function. It is a contract problem: every code path that moves skb fragments has to preserve the shared-frag bit, every time.

The kernel's zero-copy networking lets file-backed memory serve as packet data, and a single dropped flag anywhere in the chain turns a performance optimization into a write primitive. Each variant found a path where the contract was not honored.

The original DirtyFrag researcher, Hyunwoo Kim, had submitted a broader multi-site patch covering several remaining frag-transfer helpers on May 16. The combined fix was merged on May 21 (commit 48f6a5356a33), assigned CVE-2026-43503 on May 23, and shipped in Linux v7.1-rc5 on May 24.

What to Do

Install your distribution's kernel update. The fix landed upstream in v7.1-rc5 and has been backported to stable and LTS branches. Ubuntu, Debian, and SUSE have published advisories; Red Hat has a Bugzilla tracking entry.

If you cannot patch today, two workarounds reduce the attack surface. Restrict unprivileged user namespaces: on Debian and Ubuntu, set kernel.unprivileged_userns_clone=0 (other distributions use different mechanisms).

Alternatively, blacklist the esp4, esp6, and rxrpc kernel modules, though that breaks IPsec and AFS and only works when those features are loadable modules rather than compiled into the kernel. Both are temporary controls, not fixes.

The DirtyFrag class is probably not done. Any function that moves fragment descriptors without propagating the shared-frag flag is a potential new CVE, and auditing should cover every path that touches skb_shinfo()->flags during fragment transfer.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.