DirtyClone (CVE-2026-43503): Root With No Trace on Disk
Another “Dirty” is making the rounds, this time DirtyClone. It is a local privilege escalation flaw in the Linux kernel, tracked as CVE-2026-43503 with a CVSS score of 8.8. It lets an ordinary, unprivileged user become root, and it does so remarkably quietly: it overwrites a trusted binary in memory without touching it on disk. JFrog Security Research published the public exploit walkthrough on June 25th.
What the Bug Is
At the heart of the problem is a single kernel function, __pskb_copy_fclone(). When it clones a network packet (the sk_buff structure), it drops the SKBFL_SHARED_FRAG flag. That flag is a safety mechanism: it marks that the buffer fragments point to shared page-cache memory, that is, memory backed by a file on disk. When the flag is set, IPsec makes a copy before decryption instead of writing into the original pages.
By losing the flag during cloning, the kernel starts treating file-backed pages as ordinary, safely writable packet memory. This opens up a primitive for writing into someone else’s file-backed memory.
How the Attack Works
The chain is clever and comes in a few steps:
- The attacker loads a privileged binary, for example
/usr/bin/su, into memory so that its pages land in the page cache. - They wire those pages as fragments into a network packet.
- They force the packet to be cloned through the netfilter TEE target, which internally calls
nf_dup_ipv4(), which in turn calls__pskb_copy_fclone(). This is where theSKBFL_SHARED_FRAGflag is lost. - They route the packet through an IPsec tunnel they control. ESP decryption happens in place and writes attacker-controlled bytes straight into the page-cache pages belonging to
/usr/bin/su. - The permission-checking instructions in
suget overwritten. From then on, runningsugrants root.
To set all this up (the TEE rule, the IPsec tunnel, CAP_NET_ADMIN), the attacker relies on unprivileged user namespaces.
Why It Is So Dangerous
The modification lives only in kernel memory. The /usr/bin/su file on disk never changes, so:
- file-integrity tools (AIDE, Tripwire, checksums) detect nothing, because nothing changed on disk,
- the attack leaves no kernel log entries and no audit trail,
- after a reboot the original file comes back from disk, so the evidence erases itself.
This is exactly the kind of flaw that slips past classic monitoring.
The DirtyFrag Family
DirtyClone is not alone. It is the fourth bug in the same family, all sharing one root cause: file-backed memory ends up treated as packet data, and an in-place network operation writes where it should have copied.
- CVE-2026-43284 and CVE-2026-43500 (the original DirtyFrag)
- CVE-2026-46300 (Fragnesia)
- CVE-2026-43503 (DirtyClone)
Who Is Affected
Popular distributions with unprivileged user namespaces enabled are vulnerable: Debian, Fedora and Ubuntu, as long as their kernel lacks the complete chain of fixes. Multi-tenant environments are especially exposed: servers with many users, CI runners, container hosts and Kubernetes clusters where untrusted users can create namespaces.
How to Defend
Most important: update the kernel. The fix landed in mainline on May 21st (commit 48f6a5356a33) and first shipped in Linux v7.1-rc5. Backports to the stable branches followed in the next few days, so a fresh distribution kernel closes the hole.
Before you update, as a stopgap:
- Disable unprivileged user namespaces. On Debian and Ubuntu this cuts off the path to
CAP_NET_ADMIN:
sysctl -w kernel.unprivileged_userns_clone=0
- Blacklist the modules that provide the in-place decryption primitive. This disables IPsec and AFS, so do it deliberately:
echo -e "blacklist esp4\nblacklist esp6\nblacklist rxrpc" > /etc/modprobe.d/dirtyclone.conf
It also helps to run something that detects credential tampering at runtime. The LKRG module can spot a sudden, unauthorized change to a process’s privileges, which is exactly the end result of this exploit.
Timeline
- May 19, 2026: JFrog reports the bug to kernel maintainers
- May 21: fix merged into mainline (commit
48f6a5356a33), v7.1-rc5 - May 23: CVE-2026-43503 published
- around May 24: backports to stable
- June 25: JFrog publishes a detailed analysis with a working exploit
Takeaway
DirtyClone is a good reminder that the boundary between the network stack and file-backed memory is thinner than it looks. One lost flag turns an innocent packet clone into a write into someone else’s trusted file. If you run a multi-tenant machine, treat this as a priority: update the kernel, and until you do, restrict unprivileged user namespaces.
Sources: JFrog Security Research, The Hacker News, SecurityWeek, Sansec