Dirty Frag: A New Deterministic Linux Kernel Privilege Escalation Chain

A critical Linux kernel vulnerability chain, dubbed Dirty Frag, has been publicly disclosed and assigned CVE-2026-43284 and CVE-2026-43500. The vulnerability enables attackers with local access to escalate privileges to root by exploiting flaws in two kernel subsystems: the ESP (IPsec) implementation and the RxRPC transport protocol. A public proof-of-concept already exists, and organizations running mainstream Linux distributions should treat this as an actively exploitable threat under certain conditions — even before official patches are released.

Dirty Frag is the successor to Copy Fail (CVE-2026-31431), sharing its page-cache write primitive technique. It was discovered by security researcher Hyunwoo Kim (@v4bel) and is also referred to as CopyFail2 in some advisories, as the exploit was partly reconstructed by reversing the upstream fix commit.

What Makes Dirty Frag Technically Significant

Unlike many kernel exploits that rely on fragile race conditions, Dirty Frag is a deterministic, highly reliable vulnerability chain. This places it in the same threat class as Dirty Pipe (CVE-2022-0847) and the original Copy Fail — bugs that can be exploited consistently without repeated timing attempts.

The core mechanism combines two page-cache write primitives:

  • xfrm-ESP (IPsec) subsystem — affected code introduced approximately in 2017
  • RxRPC transport subsystem — affected code introduced approximately in 2023

Both primitives allow an attacker to write into page-cache-backed memory that is not exclusively owned by the kernel. By corrupting that memory, an attacker can overwrite sensitive files on disk — including setuid binaries or system configuration files — and ultimately achieve full root privilege escalation.

The two affected code paths span nearly a decade of kernel versions. Any Linux system running a kernel released since 2017 may carry the ESP flaw; systems running kernels from 2023 onward may carry both primitives simultaneously.

Prerequisites and Exploitation Constraints

Successful exploitation requires two conditions to be met simultaneously: access to the vulnerable kernel interfaces and the ability to manipulate page-backed buffers, typically via splice()-related system call paths.

A meaningful exploitation barrier exists: the attack path typically requires CAP_NET_ADMIN capability. This significantly limits the exploitability surface in hardened environments:

  • Kubernetes clusters with default seccomp profiles are substantially less exposed
  • Virtual machines and bare-metal hosts with less restricted capability assignments remain at high risk
  • Container environments granting CAP_NET_ADMIN (e.g., network-privileged pods) are directly exposed

Security teams should audit their workloads for unnecessarily elevated capabilities, as this single mitigation step dramatically reduces the practical attack surface.

Affected Linux Distributions and Products

The full impact scope is still being assessed, but the following distributions are confirmed or likely affected based on current advisories:

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

It is worth noting that this vulnerability was disclosed prior to embargo expiration after details became public through reverse engineering of the upstream fix commit, which compressed the window for coordinated patching across vendors.

Immediate Mitigations Before Patches Arrive

With no universal official patches available at time of disclosure, security teams should implement the following mitigations in order of priority:

1. Disable the Vulnerable Kernel Modules

The most direct mitigation is to block loading of the affected modules. The following command blacklists esp4, esp6, and rxrpc and attempts to unload them from a running kernel:

  • Creates /etc/modprobe.d/dirtyfrag.conf with install-blocked entries for all three modules
  • Calls rmmod to remove any already-loaded instances

Operational warning: Disabling esp4 and esp6 will break IPsec tunnel functionality. Disabling rxrpc may impact AFS (Andrew File System) environments. Assess impact on network infrastructure before applying in production.

2. Apply Patches from Vendor Repos When Available

Some distributions, including AlmaLinux testing repositories, have early patched kernels available. Monitor your vendor's security advisory channels and apply kernel updates as soon as stable patches are released. Prioritize systems that are internet-exposed or that grant users elevated capabilities.

3. Harden Local Access and Capability Assignment

  • Restrict interactive shell access to only authorized users
  • Enforce least-privilege principles and audit CAP_NET_ADMIN assignments across containers and services
  • Ensure SELinux or AppArmor is running in enforcing mode
  • Review and tighten seccomp profiles on all containerized workloads

4. Monitor for Exploitation Activity

  • Alert on abnormal privilege escalations in audit logs
  • Monitor for unexpected execution of compilers (gcc, cc) or known exploit-staging tools under non-root user accounts
  • Periodically verify the integrity of critical system binaries using tools like aide or rpm -Va

5. Post-Incident Cache Flush

If a compromise is suspected, drop the kernel's page cache to evict any potentially corrupted cached pages from memory before performing integrity checks:

  • Write 3 to /proc/sys/vm/drop_caches to force a full page, dentry, and inode cache flush
  • Follow up with a full filesystem integrity scan

Why Dirty Frag Demands Urgent Attention

The combination of a deterministic exploitation path, a wide historical kernel version range, a public proof-of-concept, and premature disclosure creates an unusually compressed response window. Most critical kernel LPEs require weeks before working exploits reach threat actors — Dirty Frag arrived with the exploit already public.

Organizations running Linux in cloud, on-premises, or hybrid environments should immediately inventory affected systems, apply module-level mitigations where operationally feasible, and escalate kernel patching to the top of their vulnerability management queue for the next maintenance window.

Conclusion

Dirty Frag (CVE-2026-43284 / CVE-2026-43500) is a serious addition to the growing catalog of deterministic Linux kernel privilege escalation vulnerabilities. Its roots in two long-standing subsystems — ESP and RxRPC — and its lineage from Copy Fail signal that page-cache write primitive research is producing a durable class of high-impact bugs. Until vendor patches are universally available, disabling vulnerable modules, hardening capability assignments, and tightening access controls are the most effective defenses. Watch vendor security channels closely: this situation is still developing.