high

CVE

CVE-2026-43284, CVE-2026-43500

CWE

CWE-123

Affected Surface

Linux kernel ESP/xfrm receive path, Linux kernel RxRPC subsystem, Linux kernel 4.10 through 7.0, Ubuntu, Debian, RHEL, Fedora, SUSE/openSUSE, AlmaLinux, Rocky Linux, Oracle Linux, CentOS Stream, Container hosts that expose AF_KEY, XFRM netlink, or AF_RXRPC to workloads

Dirty Frag is a Linux kernel local privilege escalation chain disclosed on 8 May 2026. It combines CVE-2026-43284 in the ESP/IPsec path with CVE-2026-43500 in the RxRPC subsystem to let a local attacker corrupt shared page-cache-backed memory and pivot to root.

The bug class is familiar from Dirty Pipe and Copy Fail: a kernel fast path writes into memory without adequately proving that the page belongs exclusively to the kernel operation. In Dirty Frag, in-place decryption paths can be made to write attacker-controlled bytes into the page cache for privileged files. A public proof of concept was released before broad patched-kernel availability, so teams should treat any local foothold on affected hosts as materially more dangerous.

Affected systems

The affected projects are Linux kernel networking and file-service subsystems:

  • CVE-2026-43284: Linux kernel ESP/xfrm IPsec receive handling.
  • CVE-2026-43500: Linux kernel RxRPC handling.
  • Known affected kernel range: Linux kernel 4.10 through 7.0, with distribution-specific backports and build options affecting exposure.
  • Affected distributions reported by public advisories include Ubuntu, Debian, Red Hat Enterprise Linux, Fedora, SUSE and openSUSE, AlmaLinux, Rocky Linux, Oracle Linux, and CentOS Stream.

Container platforms inherit the host kernel risk. The issue is not remotely exploitable on its own, but a compromised workload can become a host compromise if the container is allowed to create the relevant socket families or netlink paths.

Why this matters for application security

Application incidents often begin with a lower-privileged foothold: an SSRF into metadata, a leaked SSH key, a web shell, or arbitrary code execution inside one container. Dirty Frag changes the post-exploitation math because that foothold can become root on the host if the kernel and runtime policy expose the vulnerable primitives.

The most exposed environments are multi-tenant build systems, self-hosted CI runners, shared Kubernetes nodes, and developer workstations where untrusted code can run with ordinary user privileges.

Exploit shape

Public analysis describes two page-cache write primitives:

  • ESP/IPsec in-place receive processing can be steered through xfrm configuration and crafted packets.
  • RxRPC can be used as an alternate path on systems where the ESP route is constrained but the RxRPC module is available.

The end state is the same: attacker-controlled bytes are written into the in-memory page cache for a privileged file such as a setuid binary. The file on disk may remain unchanged, which makes purely disk-based integrity checks insufficient.

Unlike many kernel privilege escalations, the reported exploit path is deterministic rather than timing-race dependent.

Remediation

Apply vendor kernel updates as soon as they are available for the distribution and kernel line you run. Because patch timing varies across vendors, do not assume one distribution’s fixed status applies to another.

Where IPsec transport and AFS/RxRPC are not required, temporarily prevent vulnerable modules from loading:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

Regenerate initramfs where your distribution requires it so modules are not loaded during early boot. Test first: disabling esp4 or esp6 can break IPsec, and disabling rxrpc can affect AFS environments.

For containers and CI runners, restrict access to AF_KEY, AF_RXRPC, and xfrm netlink operations through seccomp, AppArmor, SELinux, and capability policy. Avoid granting CAP_NET_ADMIN unless a workload has a specific, reviewed need.

Detection and response

Prioritize runtime telemetry over file checks alone. Useful signals include:

  • Unexpected creation of AF_RXRPC sockets by non-AFS processes.
  • Unprivileged xfrm or AF_KEY activity.
  • splice() and vmsplice() activity paired with network socket setup from unusual processes.
  • Unexpected privilege transitions after setuid binary execution.
  • Attempts to load esp4, esp6, or rxrpc modules on systems that do not normally use IPsec or AFS.

If a system may have been exploited, rebooting after patching clears poisoned page-cache state, but incident response should still treat the original local account or container foothold as compromised. Rotate credentials reachable from the host and review workloads that ran on the affected node.

References