pedit COW & DirtyClone: Two New Linux Root Exploits That Bypass On-Disk Integrity Checks

An unprivileged user on your Linux server runs a single command and gets a root shell. Your file integrity monitor shows nothing. The binary on disk is untouched. For DirtyClone, even the kernel audit log comes up empty. This is not a hypothetical — it is the reality of two vulnerabilities disclosed in June 2026.

TL;DR

• CVE-2026-46331 (pedit COW): Out-of-bounds write in the kernel’s traffic control subsystem corrupts the in-memory page cache of /bin/su, granting a root shell — public PoC available since June 17
• CVE-2026-43503 (DirtyClone): A follow-up variant in the DirtyFrag family — a dropped safety flag during packet cloning lets an attacker overwrite privileged binaries in memory via IPsec decryption, CVSS 8.8; JFrog confirmed it leaves no kernel audit trail
• Both attacks bypass AIDE, Tripwire, and similar tools because no on-disk files change
• Both attacks need CAP_NET_ADMIN — most commonly obtained via unprivileged user namespaces, which are enabled by default on RHEL, Debian, and Ubuntu
• Patch: Apply your distro’s fixed kernel — check your vendor’s security advisory for the relevant backport

Why This Matters

These two vulnerabilities share a deeply uncomfortable property: they are silent by design. Every traditional defense — file hashing, audit logs, on-disk integrity checks — fails to detect them, because the attacks never touch disk. They corrupt the kernel’s in-memory copy of files instead.

The target is almost always the same: a privileged SUID binary like /bin/su. The attacker poisons its in-memory representation with shellcode, executes it, and gets root. The binary on disk remains unchanged. In the case of DirtyClone, JFrog confirmed that the attack generates no kernel log or audit entries either.

If you are running a Linux system with default kernel settings and have not patched since mid-May 2026, you are almost certainly vulnerable to at least one of these.

CVE-2026-46331 — pedit COW

What Is It

CVE-2026-46331 is an out-of-bounds write in act_pedit — the Linux kernel module responsible for editing packet headers in the tc (traffic control, a network packet management framework) subsystem.

The flaw is a classic copy-on-write (COW) mistake: the kernel is supposed to make a private copy of memory before editing it. Here, that copy covers the wrong range, so writes end up landing in the shared page cache — the kernel’s global in-memory store of file contents.

How the Exploit Works

The attack chain has three steps:

Step 1 — Get CAP_NET_ADMIN. The attacker creates an unprivileged user namespace. Inside that namespace, they automatically hold CAP_NET_ADMIN (a capability to manage network settings). This is enough to invoke act_pedit.

Step 2 — Corrupt the page cache. The attacker uses act_pedit to trigger the COW violation, targeting the in-memory copy of /bin/su. They overwrite the binary’s entry point with a short shellcode sequence: setgid(0) → setuid(0) → execve("/bin/sh").

Step 3 — Trigger the payload. The attacker runs /bin/su. The kernel executes the poisoned in-memory image. A root shell drops.

The on-disk /bin/su is unchanged. AIDE and Tripwire compare hashes of on-disk files — they see nothing.

# Conceptual flow — not a copy-paste exploit, just to illustrate the approach
unshare -Urm   # create user namespace, gain CAP_NET_ADMIN inside it
# --> use act_pedit to corrupt /bin/su page cache entry
# --> execute /bin/su
# --> root shell

Timeline

The CVE was assigned on June 16, 2026 and a public, weaponized proof-of-concept appeared on GitHub the following day — a 24-hour window between disclosure and working exploit code.

Red Hat published security advisory RHSB-2026-008 confirming successful exploitation on RHEL 10, with RHEL 8 and 9 also listed as affected.

Affected Systems

Any kernel from v5.18 through v7.1-rc6 is affected. The patch is in v7.1-rc7 and later.

Immediate Mitigation

If you cannot patch immediately, block act_pedit from auto-loading:

echo "blacklist act_pedit" | sudo tee /etc/modprobe.d/blacklist-act-pedit.conf
sudo modprobe -r act_pedit 2>/dev/null

This prevents the module from loading on next boot. If it is already loaded, verify with lsmod | grep act_pedit and remove it if present.

CVE-2026-43503 — DirtyClone

The DirtyFrag Family

To understand DirtyClone, you need context on its predecessors. In May 2026 we covered Dirty Frag — a pair of kernel bugs (CVE-2026-43284 and CVE-2026-43500) that exploited the way socket buffers reference shared page-cache memory.

DirtyClone is another variant and follow-up in the same DirtyFrag family. The researchers at JFrog Security Research found that the mitigation introduced by the DirtyFrag patches was itself incomplete — it left a new path exposed.

What Is It

CVE-2026-43503 lives in the function __pskb_copy_fclone() — the kernel routine that duplicates a network packet (socket buffer, or “skb”). When the netfilter TEE target (a tool that duplicates packets and sends them to another destination) clones a packet, this function is called.

The problem: the function drops the SKBFL_SHARED_FRAG safety flag from the clone. This flag is the kernel’s marker that says “this packet’s memory is backed by a file — do not write to it in-place.” The clone loses the flag. The kernel then treats the cloned packet’s memory as safe to modify directly.

The Attack Chain

JFrog published a full working exploit walkthrough on June 25, 2026. The attack has seven stages:

1. Map the target binary. Load /usr/bin/su into memory using normal file operations.
2. Wire pages into a network packet. Use vmsplice() to splice the file-backed memory pages into a network socket buffer, linking them to a live packet.
3. Establish an IPsec loopback tunnel. Set up an IPsec ESP (the encryption protocol used in VPNs) tunnel that the attacker controls entirely.
4. Trigger the vulnerable clone. Send the packet through the netfilter TEE target, forcing __pskb_copy_fclone() to clone it — dropping the safety flag.
5. Route clone through IPsec decryption. The unflagged clone enters the IPsec ESP decryption path.
6. Controlled write via AES-CBC. IPsec decryption performs in-place AES-CBC decryption — a mathematical transformation that writes attacker-chosen bytes back into the memory. Because the safety flag is gone, the kernel writes directly into the page-cache pages backing /usr/bin/su.
7. Execute. Call /usr/bin/su. The kernel runs the poisoned in-memory image. Root shell.

The elegance of this attack is that it repurposes a legitimate cryptographic operation (AES decryption) as a write primitive. No kernel panic, no unusual syscalls beyond what a normal VPN tunnel would produce.

Affected Systems

CVE-2026-43503 affects any kernel before v7.1-rc5, which was released May 24, 2026. However, the patch is not a single commit — it is a series of four CVEs that must all be applied:

Distributions that backported only part of the series may still be vulnerable to DirtyClone even if they patched the original DirtyFrag bugs. Confirm that your kernel includes all four fixes.

Confirmed vulnerable with default configuration: Debian, Ubuntu, Fedora. Ubuntu 24.04+ has AppArmor restrictions on user namespaces that raise the bar but do not eliminate the vulnerability.

Immediate Mitigation

Restrict unprivileged user namespaces (this blocks the namespace-based privilege acquisition used in the attack):

# Debian/Ubuntu
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo "kernel.unprivileged_userns_clone=0" | sudo tee -a /etc/sysctl.d/99-security.conf

# RHEL/Fedora
sudo sysctl -w user.max_user_namespaces=0
echo "user.max_user_namespaces=0" | sudo tee -a /etc/sysctl.d/99-security.conf

If you do not use IPsec VPN or AFS (Andrew File System), also blacklist the relevant modules:

echo -e "blacklist esp4\nblacklist esp6\nblacklist rxrpc" | sudo tee /etc/modprobe.d/blacklist-dirtyclone.conf

The Common Thread: Silent Page Cache Attacks

What makes June 2026 notable is that these are two independent vulnerabilities, found separately, that converge on the same attack surface: the Linux kernel page cache.

The page cache is the kernel’s in-memory store of file contents — every file you access is cached here for performance. Both CVE-2026-46331 and CVE-2026-43503 exploit paths where the kernel writes into this cache without respecting write-protection semantics.

The result is an attack class that is fundamentally invisible to the most common Linux integrity tools:

This is a qualitative shift from most LPE vulnerabilities, which either write suspicious files to disk or generate detectable audit events.

Detection

Traditional monitoring misses both of these attacks. Here are approaches that do have some signal:

1. Monitor user namespace creation. Both attacks typically use unprivileged user namespaces as the path to obtaining CAP_NET_ADMIN. Add this to your auditd rules:

-a always,exit -F arch=b64 -S clone -F a0&0x20000000 -k user_ns_create
-a always,exit -F arch=b64 -S unshare -F a0&0x20000000 -k user_ns_create

High volume of user_ns_create events from non-containerized processes is a red flag.

2. Watch for unexpected kernel module loads. If act_pedit, esp4, or esp6 suddenly load on a system that does not use traffic shaping or IPsec, investigate.

# Real-time module load monitoring
journalctl -k -f | grep -E "act_pedit|esp4|esp6|rxrpc"

3. Correlate namespace creation with SUID execution. An unprivileged process creating a user namespace and then executing a SUID binary within a short time window is a strong indicator. This can be caught by eBPF-based tools like Falco or Tetragon.

4. Verify running kernel version. Check that your running kernel is v7.1.1 or newer (or carries the backport):

uname -r

For DirtyClone specifically, confirm all four CVEs are in your distro’s patch list:

# Debian/Ubuntu
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -E "CVE-2026-4(3503|3284|3500|6300)"

# RHEL/Fedora
rpm -q --changelog kernel | grep -E "CVE-2026-4(3503|3284|3500|6300)"

# Arch-based (check kernel package log)
pacman -Qc linux | grep -E "CVE-2026-4(3503|3284|3500|6300)"

What You Can Do Today

If you can patch (preferred):

• Apply your distro’s patched kernel (requires mainline v7.1-rc7+ for pedit COW, v7.1-rc5+ for DirtyClone) — check your vendor’s security advisory for the exact backport version
• For DirtyClone: verify your distro applied the full four-CVE patch series — partial backports leave the door open
• Check Red Hat, Debian, Ubuntu, and Fedora security advisories for your specific release

If you cannot patch immediately:

• Block act_pedit for pedit COW (see above)
• Restrict user namespaces or blacklist esp4/esp6/rxrpc for DirtyClone (see above)
• Both mitigations together significantly raise the exploitation barrier

Detection layer:

• Add the auditd rules for user namespace creation
• Enable eBPF-based runtime monitoring (Falco or Tetragon) if not already in use
• Do not rely on AIDE/Tripwire alone — these attacks are designed to bypass them

Related Posts

• Dirty Frag & Copy Fail: Two New Linux Kernel Vulnerabilities Grant Root Privileges — The original DirtyFrag family (CVE-2026-43284/43500) and Copy Fail from May 2026 — essential context for understanding DirtyClone
• Linux Privilege Escalation: Attack & Detect — Broader guide to Linux LPE techniques and detection strategies
• SSH-keysign-pwn: The Nine-Year Linux Kernel Flaw — Another recent Linux kernel vulnerability from May 2026 worth patching
• Linux Default Attack Surface — What features are enabled by default and why they matter for attackers

Sources

• RHSB-2026-008 — Red Hat Security Bulletin (CVE-2026-46331)
• pedit COW CVE-2026-46331 — TuxCare
• New Linux pedit COW Exploit — CybersecurityNews
• Dissecting and Exploiting DirtyClone (CVE-2026-43503) — JFrog Security Research
• New DirtyClone Linux Kernel Flaw — The Hacker News
• Linux Gets Dirty Again: DirtyClone — Linuxiac
• CVE-2026-46331 — OpenCVE