DirtyClone: New DirtyFrag-Family Kernel Bug Hands Local Users Root

A new Linux kernel local privilege escalation in the DirtyFrag lineage has a public exploit walkthrough, and the bug itself rates a CVSS 8.8.

The flaw, CVE-2026-43503, lets an unprivileged local user corrupt file-backed memory by abusing how the kernel handles a cloned network packet (specifically, the skb_clone path interacting with the page cache). The end state is the familiar one: arbitrary write into a read-only file mapping, then root.

JFrog Security Research published the writeup and a working PoC on June 25. It is the first public demonstration of this DirtyFrag variant, and the researchers walk through the race window, the heap-grooming primitive, and the final overwrite against a SUID binary.

The DirtyFrag family is a known quantity at this point. DirtyPipe (CVE-2022-0847) kicked things off, DirtyCred followed, and each variant tends to chip away at whatever mitigation was bolted on after the last one. DirtyClone fits the pattern: it sidesteps the post-DirtyCred hardening by reaching the same corruption primitive through the network stack instead of the pipe subsystem.

What that means operationally:

• Any local code execution context — a web shell, a compromised service account, an SSH foothold on a jump box — becomes a plausible root.
• Containers sharing the host kernel are in scope. Namespacing does not save you here; the bug lives below the container boundary.

The fix is in mainline. Patched kernels are 6.6.58, 6.11.5, and the 6.12-rc series from -rc4 forward. Distribution backports are landing now, and defenders should treat the public PoC as a starting gun rather than a curiosity.

A few things worth flagging.

The CVSS 8.8 reflects local attack vector with low complexity and no user interaction. It does not require any unusual capability — no CAP_NET_ADMIN, no user namespaces toggle (which some distros still ship disabled by default for unprivileged users). That lowers the bar considerably compared to several recent net/* bugs.

The PoC, as published, targets x86_64 with a specific allocator layout. Porting to arm64 is left as an exercise, but nothing in the underlying primitive is architecture-specific. Expect variants within days.

Detection is awkward. There is no clean syscall signature; the exploit looks like normal socket activity until the overwrite happens. EDR vendors that hook page-cache writes against immutable mappings will catch it. Most will not, at least not on day one.

If you run Linux at scale, the move is to push the patched kernel through your normal ring, prioritize multi-tenant hosts and anything exposed to untrusted local code, and audit which workloads are still on long-term-support kernels that have not yet received the backport. Stable trees from 5.10 onward are reportedly affected; older LTS branches are still under analysis.

The kernel security list thread on the disclosure timeline is worth a read if you want the upstream context.