A newly disclosed Linux kernel privilege-escalation chain tracked as CVE-2026-43284 and CVE-2026-43500 — nicknamed Dirty Frag — lets a local attacker climb to root by abusing page-cache write primitives in two kernel subsystems: the ESP/IPsec stack and the RxRPC transport protocol. Unlike race-condition exploits, the chain is deterministic and reliable, and a public write-up plus proof-of-concept already exist. Because the affected code reaches back to 2017 and details leaked through reverse-engineering of the upstream fix, defenders running mainstream distributions should treat this as actively exploitable under the right conditions, even ahead of universal vendor patches.

What Dirty Frag is

Dirty Frag is the direct descendant of Copy Fail (CVE-2026-31431) and reuses the same page-cache write technique — which is why some advisories label it CopyFail2. It was found by security researcher Hyunwoo Kim (@v4bel), and parts of the working exploit were reconstructed by reversing the kernel's upstream fix commit. The corresponding exploit-db entry, published by nu11secur1ty on 2026-05-11, names the technique "Kukurigu."

What sets it apart from most kernel local privilege escalations (LPEs) is determinism. Like Dirty Pipe (CVE-2022-0847) and the original Copy Fail, it does not depend on winning a timing window — the exploit-db write-up describes a near-100% success rate on tested systems, with no kernel panics on failure. That stability, combined with a public PoC and pre-embargo disclosure, compresses the usual weeks-long gap between disclosure and weaponization down to essentially zero.

The two-bug chain

Dirty Frag stitches together two independent page-cache write primitives. Both let an attacker write into page-cache-backed memory that the kernel does not exclusively own; corrupting those cached pages allows on-disk overwrites of sensitive files such as setuid binaries (/usr/bin/su, /usr/bin/sudo) or /etc/passwd, effectively poisoning the execution environment.

  • CVE-2026-43284 — xfrm-ESP (IPsec). A logic flaw in the ESP implementation when Extended Sequence Numbers (ESN) are active gives a local user an arbitrary 4-byte write directly into the page cache. The NVD entry (May 8, 2026) summarizes the upstream fix as xfrm: esp: avoid in-place decrypt on shared skb frags, noting the issue arises via MSG_SPLICE_PAGES. This code path was introduced around 2017.
  • CVE-2026-43500 — RxRPC. A flaw in the RxRPC transport protocol enables in-place decryption of data within page-cache pages. This subsystem code dates to roughly 2023.

The exploit-db write-up pins the vulnerable window to kernels released between 2017-01-17 and 2026-05-10. In practice, any kernel from 2017 onward may carry the ESP primitive; kernels from 2023 onward may carry both at once. (Note: although the "Frag" nickname and one community thread reference "memory fragmentation," the authoritative NVD and exploit-db descriptions both characterize the underlying mechanism as a page-cache write, not a fragmentation bug.)

Exploitation prerequisites

Two conditions must hold simultaneously: reachable vulnerable kernel interfaces, and the ability to drive page-backed buffers — typically through splice()-style system-call paths. Crucially, the attack path generally needs the CAP_NET_ADMIN capability, which meaningfully narrows the practical attack surface:

  • Kubernetes clusters running default seccomp profiles are substantially less exposed.
  • VMs and bare-metal hosts with looser capability assignments remain at high risk.
  • Containers granted CAP_NET_ADMIN (network-privileged pods) are directly exposed.

Auditing workloads for unnecessary capabilities is therefore one of the highest-leverage mitigations available.

Affected distributions

Scope is still being assessed, but current advisories list the following as confirmed or likely affected:

  • Linux kernel — ESP subsystem (since ~2017) and RxRPC subsystem (since ~2023)
  • Ubuntu — multiple versions, confirmed tested and affected
  • Red Hat Enterprise Linux (RHEL) 8, 9, and 10
  • CentOS Stream 10
  • AlmaLinux 8, 9, and 10
  • Fedora (recent versions)
  • openSUSE Tumbleweed
  • OpenShift 4 — potentially affected, under investigation

Because details became public through reverse-engineering of the fix commit before embargo expiry, the coordinated-patching window across vendors was cut short.

Mitigations before patches land

The commands below are standard administrative hardening steps that implement the mitigations described in the advisory — they are not the researcher's exploit. Test their operational impact before applying in production.

1. Block the vulnerable modules

The most direct mitigation is to prevent esp4, esp6, and rxrpc from loading and to unload any running instances. Create /etc/modprobe.d/dirtyfrag.conf:


install esp4 /bin/true
install esp6 /bin/true
install rxrpc /bin/true

Then unload anything already resident:


rmmod esp4 esp6 rxrpc

Operational warning: disabling esp4/esp6 breaks IPsec tunnels, and disabling rxrpc can break AFS (Andrew File System) environments. Assess network impact first.

2. Apply vendor patches as they ship

Some vendors — including AlmaLinux testing repositories — already have early patched kernels. Watch your distribution's security advisory channels and prioritize internet-exposed hosts and any system that grants users elevated capabilities.

3. Tighten local access and capabilities

  • Restrict interactive shell access to authorized users only.
  • Audit CAP_NET_ADMIN assignments across containers and services and enforce least privilege.
  • Keep SELinux or AppArmor in enforcing mode.
  • Review and tighten seccomp profiles on all containerized workloads.

4. Monitor for exploitation

  • Alert on abnormal privilege escalations in audit logs.
  • Flag unexpected compiler execution (gcc, cc) or exploit-staging tools run by non-root users.
  • Periodically verify the integrity of critical binaries:

rpm -Va          # RPM-based distros
aide --check     # if AIDE is deployed

5. If you suspect compromise, flush the page cache

Because the attack lives in cached pages, drop the kernel's caches to evict any poisoned pages before running integrity checks:


echo 3 > /proc/sys/vm/drop_caches

The value 3 forces a flush of the page, dentry, and inode caches; follow it with a full filesystem integrity scan.

Why this one is urgent

Deterministic exploitation, a kernel version range spanning nearly a decade, a public PoC, and premature disclosure together produce an unusually tight response window. Most serious kernel LPEs give defenders weeks before working exploits circulate — Dirty Frag arrived with the exploit already public. Inventory affected systems now, apply module-level mitigations where operationally feasible, and move kernel patching to the front of your vulnerability-management queue. Its lineage from Copy Fail and its roots in two long-lived subsystems suggest page-cache write-primitive research will keep producing high-impact bugs, so monitor vendor channels closely — this situation is still developing.

References