DirtyClone: New Kernel Privilege Escalation Lets Local Users Gain Root by Corrupting Cloned Packets
Researchers at JFrog Security Research published a working exploit walkthrough on June 25 for a newly disclosed Linux kernel privilege-escalation vulnerability in the DirtyFrag family. Tracked as CVE-2026-43503 with a CVSS score of 8.8, the bug-nicknamed DirtyClone-allows a local attacker to corrupt file-backed memory via a cloned network packet and elevate to root. The upstream patch was merged in mainline Linux on May 21; systems that have not received that fix should be updated immediately.
The flaw stems from two internal helper routines that, when the kernel copies a network packet, inadvertently clear a safety flag that signals the packet’s memory is shared with a file on disk. That dropped flag is the root cause. In a practical exploit, an attacker maps a privileged binary such as /usr/bin/su into memory, binds those pages into a network skb (socket buffer), and provokes the kernel into cloning the packet. The clone is routed through an IPsec tunnel under the attacker’s control and, during the tunnel’s decryption stage, in-place writes overwrite the binary’s authentication checks with attacker-supplied bytes. On the next execution of su, the altered in-memory image hands over root privileges.
Crucially, the attack never modifies the on-disk file. The corruption exists only in the kernel’s memory copy, so file-integrity tools won’t detect it, auditing records can be absent, and a reboot restores the original binary image-by then the attacker already has root. Carrying out the exploit requires CAP_NET_ADMIN to create and configure a loopback IPsec tunnel. Because Debian and Fedora enable unprivileged user namespaces by default, a local user can gain that capability inside a newly created namespace. Ubuntu 24.04 and later mitigate the default attack path by restricting namespace creation with AppArmor. Because the page cache is shared at the host level, any in-memory modification made from within a namespace affects all processes on the machine.
The most exposed environments are multi-tenant hosts, CI runners, container platforms, and Kubernetes clusters where untrusted actors can spawn namespaces. JFrog reproduced the exploit on Debian, Ubuntu, and Fedora systems with default namespace settings.
DirtyClone is the fourth recent escalation that abuses the same fundamental mistake: treating file-backed pages as packet data and performing network operations that write in place rather than copying. The series began in late April with Copy Fail (CVE-2026-31431), which abused the algif_aead module to achieve a four-byte write into the page cache. On May 7, DirtyFrag (CVE-2026-43284 and CVE-2026-43500) chained IPsec ESP and RxRPC paths to gain a full write primitive. On May 13, Fragnesia (CVE-2026-46300) bypassed an earlier DirtyFrag patch via a flag-dropping bug in skb_try_coalesce(). Each fix covered a specific code path, but other transfer helpers remained vulnerable.
The exploit demonstrated for DirtyClone targets __pskb_copy_fclone(), with skb_shift() also implicated. The broader CVE remediation addresses multiple frag-transfer helpers where the shared-frag bit could be lost. The underlying issue is not a single faulty helper; it’s a contract violation: every code path that moves skb fragments must preserve the shared-frag flag consistently. Linux’s zero-copy networking optimization allows file-backed memory to be used as packet buffers, and a dropped bit turns that optimization into a write primitive. Hyunwoo Kim, the researcher behind the original DirtyFrag report, submitted a multi-site patch on May 16 to cover several remaining frag-transfer helpers. The combined fix was merged on May 21 (commit 48f6a5356a33), was assigned CVE-2026-43503 on May 23, and appeared in Linux v7.1-rc5 on May 24.
What you should do: apply your distribution’s kernel update. The upstream correction is present in v7.1-rc5 and has been backported to stable and long-term support (LTS) branches. Ubuntu, Debian, and SUSE have published advisories; Red Hat has a Bugzilla entry tracking the issue. If immediate patching is not possible, there are two mitigations that reduce exposure.
First, disable unprivileged user namespaces to block the common exploit path: on Debian and Ubuntu set kernel.unprivileged_userns_clone=0 (other distributions use different controls). Second, blacklist the esp4, esp6, and rxrpc kernel modules to prevent the vulnerable IPsec and RxRPC paths from being used-note this breaks IPsec and AFS functionality and only works when those features are modules rather than built into the kernel. Both options are temporary risk mitigations, not replacements for a kernel patch.
The DirtyFrag family is unlikely to be finished. Any kernel helper that transfers fragment descriptors without copying forward the shared-frag flag represents a potential new CVE. Auditors and developers should examine every code path that touches skb_shinfo()->flags during fragment transfer to ensure the shared-frag bit is preserved.