JFrog Security Research published a full working exploit walkthrough for CVE-2026-43503, dubbed DirtyClone, on June 25, 2026. The flaw sits in the Linux kernel’s socket-buffer (skb) cloning path and lets any unprivileged local user escalate to root without leaving a trace in kernel audit logs or touching the binary on disk. Downstream distribution backports are still in progress across major enterprise Linux releases as of this writing.

What Happened

DirtyClone is the third publicly-weaponized member of a growing Linux page-cache LPE family (after DirtyFrag/CVE-2026-43284/CVE-2026-43500 and DirtyDecrypt/CVE-2026-31635). Unlike its siblings, which abused the rxrpc and rxgk transport layers, DirtyClone reaches the same vulnerable page-cache pages through a different code path: the generic skb_clone() and pskb_copy() helpers used by every in-kernel packet copy operation.

Technical Details

The root cause is a pair of missing flag updates in the kernel’s skb cloning path. When the kernel copies a socket buffer internally, two helper functions drop the SKBFL_ZEROCOPY_FRAG safety flag that marks the buffer’s data pages as shared with a file on disk. With that flag absent, the kernel stops treating the pages as read-only file-backed memory and permits further writes into them.

The exploit chain proceeds as follows:

  1. Stage the target. The attacker maps /usr/bin/su (or any setuid binary) into the process address space, pinning its page-cache pages in memory.
  2. Wire the pages into a packet. The attacker uses MSG_ZEROCOPY to transmit a raw packet whose data pages are the same physical pages backing /usr/bin/su.
  3. Force a clone. The packet is injected into the local network stack and routed through an attacker-controlled IPsec tunnel. The kernel calls skb_clone() as part of the ESP crypto path, losing the safety flag.
  4. Decrypt into page cache. The IPsec decryption step (esp_input) writes the decrypted payload directly into the shared page-cache pages, overwriting the in-memory copy of the setuid binary with attacker-supplied bytes—typically a small payload that executes /bin/bash as root.
  5. Execute. Running su from any terminal now triggers the overwritten code and drops a root shell.

The attack requires CAP_NET_ADMIN, which on nearly every default Ubuntu, Debian, and Fedora installation is freely obtainable by unprivileged users via unprivileged user namespaces (/proc/sys/kernel/unprivileged_userns_clone set to 1).

Affected versions: Linux kernel 6.1 through 7.1-rc4. The fix—two skbfl_set() calls restoring the safety flag after cloning—landed in v7.1-rc5 as commit 9e171fc1d7d7 on May 21, 2026. Older stable series (5.15 LTS, 5.10 LTS) are under investigation; patches have not yet been confirmed upstream for those branches.

CVSS: 8.8 (High) — Local, low complexity, low privileges required, no user interaction, high impact on confidentiality/integrity/availability.

Why This Is Particularly Dangerous

No audit trail. The attack modifies the kernel’s page-cache copy of the binary in memory. The on-disk binary remains byte-for-byte identical, passes sha256sum and rpm -V / dpkg -V verification, and leaves nothing in /var/log/audit. Incident responders may not notice the compromise until the root shell executes.

Container and Kubernetes environments. If user namespaces are enabled (the default in most managed Kubernetes node images), any process inside a non-privileged container can obtain the CAP_NET_ADMIN capability within its own namespace and run the full exploit chain. Under configurations where container processes share the host’s page cache for host-mounted volumes or where the node runs a vulnerable kernel version, this can lead to a container escape and full node compromise.

Cloud multi-tenancy. Cloud VMs running stock distribution kernels in the 6.1–7.1-rc4 range are affected if the kernel is not yet patched. A compromise of any low-privileged process—a web app, a CI runner, a serverless execution environment—can become a full VM takeover.

Who Is Affected

  • Any system running Linux kernel 6.1 through 7.1-rc4 where unprivileged user namespaces are enabled.
  • Ubuntu 22.04 LTS, 24.04 LTS, 25.04, and 26.04 are all confirmed vulnerable (all ship kernels in the affected range with unprivileged userns enabled by default).
  • Debian 12 (Bookworm) and 13 (Trixie), RHEL 10, Fedora 40–42, and Amazon Linux 2023 are affected. Distribution advisories are pending.
  • Kubernetes worker nodes using any of the above distributions are at elevated risk.

Mitigation

Patch first. Apply the kernel update for CVE-2026-43503 as soon as your distribution ships it. Check your distribution’s security advisory tracker; backports are expected for all major LTS series within days.

Restrict user namespaces (short-term workaround). On Debian/Ubuntu systems:

1

sysctl -w kernel.unprivileged_userns_clone=0

Persist the setting in /etc/sysctl.d/99-no-unpriv-userns.conf. Note this breaks rootless container runtimes (Podman, rootless Docker, most sandboxed browsers).

Blacklist IPsec kernel modules if ESP tunnels are not in use:

1
2

echo "install esp4 /bin/true" >> /etc/modprobe.d/disable-esp.conf
echo "install esp6 /bin/true" >> /etc/modprobe.d/disable-esp.conf

This prevents the attacker from setting up the decryption path required for the exploit’s final stage.

Runtime monitoring. Deploy file-integrity monitoring at the inode level rather than relying on disk-based hash checks, and alert on unexpected seteuid(0) or setuid(0) syscalls from processes that do not normally require root.

References