DirtyClone (CVE-2026-43503) — named in the lineage of Dirty COW and Dirty Pipe — is a high-severity (CVSS 8.8) Linux kernel local privilege escalation. When the kernel clones a network packet, the helper __pskb_copy_fclone() drops the SKBFL_SHARED_FRAG flag that marks the packet's memory as shared with a file on disk. That single missing flag lets an attacker corrupt kernel memory and overwrite the in-memory copy of a privileged binary like /usr/bin/su, escalating to root.

The fix merged to mainline on May 21, 2026 (commit 48f6a5356a33), first appearing in tag v7.1-rc5 (May 24). The highest risk is to multi-tenant cloud, Kubernetes, and container hosts where user namespaces are available.

What the Vulnerability Is

When the kernel needs to deliver a packet to multiple destinations, it clones the socket buffer (skb). The SKBFL_SHARED_FRAG flag exists to record that a packet's page fragments are shared with an on-disk file — a signal the kernel relies on to handle copy-on-write correctly so it never writes through to file-backed memory.

__pskb_copy_fclone() fails to preserve that flag during the clone. With the safety marker gone, the kernel treats file-backed, shared pages as if they were private and writable. The exploit weaponizes this directly:

  1. Load a privileged binary such as /usr/bin/su into memory as file-backed pages.
  2. Wire those pages into a network packet and force the kernel to clone it.
  3. Route the cloned packet through an IPsec tunnel the attacker controls — the decryption step writes attacker-chosen bytes over the binary's login checks in the (wrongly-shared) page-cache copy.

The result is root execution. The attack is silent: it leaves no kernel logs or audit traces and bypasses common on-disk integrity monitoring, because the on-disk file is never modified.

Why It Matters

  • High severity, real-world reach. At CVSS 8.8 this is a clean local-to-root primitive, and public write-ups (JFrog and others) already exist.
  • Containers and clusters are the bullseye. Exploitation needs CAP_NET_ADMIN, frequently obtainable through unprivileged user namespaces (enabled by default on Debian/Fedora). That makes multi-tenant servers, CI runners, container hosts, and Kubernetes nodes the highest-risk targets.
  • Stealth defeats disk-based detection. Because the corruption hits the page-cache image and not the file, integrity monitors watching /usr/bin/su on disk will not see the tamper.

Am I Affected?

You're at risk if the host runs a kernel without commit 48f6a5356a33 (anything before v7.1-rc5 or the backported fixes), and a local user can obtain CAP_NET_ADMIN — most commonly via unprivileged user namespaces. Container hosts, Kubernetes nodes, and any multi-tenant box giving out local shells are the priority.

Remediation

Update the kernel — first choice

Ubuntu, Debian, SUSE, and Red Hat have all published advisories. Install the distribution kernel that carries the backported fix (mainline fix: commit 48f6a5356a33, first tag v7.1-rc5) and reboot.

If you can't patch now, restrict user namespaces

# Debian/Ubuntu style
sysctl -w kernel.unprivileged_userns_clone=0

# Broadly applicable
sysctl -w user.max_user_namespaces=0

Validate first — browsers, container runtimes, and some sandboxes use user namespaces.

Temporarily blacklist the IPsec/RXRPC modules

The decryption step rides IPsec. As a temporary measure on hosts that don't need them:

printf 'blacklist esp4\nblacklist esp6\nblacklist rxrpc\n' > /etc/modprobe.d/dirtyclone-mitigation.conf

This is a stopgap, not a fix — only apply where it won't break legitimate IPsec/AFS usage. Patch container and Kubernetes hosts first: a vulnerable kernel under a container runtime means a single compromised pod can reach host root.

Quick-Win Checklist

  • Install the distro kernel carrying the 48f6a5356a33 fix (≥ v7.1-rc5 or backport) and reboot.
  • Patch container hosts and Kubernetes worker nodes first.
  • Restrict unprivileged user namespaces where workloads don't need them.
  • As a temporary stopgap, blacklist esp4 / esp6 / rxrpc on hosts that don't use IPsec/AFS.
  • Don't rely on on-disk integrity monitoring to catch this — the file is never touched.
  • Confirm which hosts grant CAP_NET_ADMIN (directly or via namespaces) and prioritize them.

Sources