Dirty Frag: A 9‑Year‑Old Linux Kernel LPE Chain That Gives Root with One Command

Vulnerability Overview

Dirty Frag combines two Linux kernel local‑privilege‑escalation bugs. CVE‑2026‑43284 affects the esp4 and esp6 modules of the IPsec ESP protocol and provides a 4‑byte arbitrary‑write primitive. CVE‑2026‑43500 affects the rxrpc module used by the AFS distributed file system and grants namespace‑creation rights. Chaining the two primitives allows modification of system binaries and escalation to root.

Root Cause

The kernel mishandles shared page fragments during splice / sendfile calls. In the in‑kernel decryption path the pages are treated as private data, letting a non‑privileged process retain a reference to decrypted plaintext, write to the page cache, and overwrite binaries.

Relation to Copy Fail

Copy Fail (CVE‑2026‑31431) used a single exploitation path via algif_aead and relied on a race condition. Dirty Frag uses two independent paths (ESP and RxRPC), bypasses the algif_aead blacklist, and does not depend on a race, making it more stable.

Historical Comparison

Dirty Cow (2016) – low stability, no constraints.

Dirty Pipe (2022) – high stability, write locations limited.

Copy Fail (April 2026) – medium stability, single path.

Dirty Frag (May 2026) – high stability, dual path, flexible writes.

Affected Distributions

All Ubuntu LTS releases from 14.04 through 26.04 are vulnerable. The vulnerability has been present since at least 2017 and also affects mainstream Linux distributions released in the past nine years (RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, etc.).

Container‑Environment Risk

Standard deployment – high: local user can gain root; PoC publicly available.

Container host – high: compromised container can escape to host root.

K8s/OpenShift node – high: multi‑tenant clusters face greatest risk.

Pure container escape – medium: no direct PoC yet, but post‑escalation impact is severe.

Emergency Mitigation (3 steps)

Step 1 – Disable vulnerable modules

# Disable esp4, esp6, rxrpc module loading
 echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
 echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
 echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
 # Update initramfs to prevent loading at boot
 sudo update-initramfs -u -k all

Step 2 – Unload loaded modules

# Unload the three modules if they are already loaded
 sudo rmmod esp4 esp6 rxrpc 2>/dev/null

Step 3 – Verify modules are not loaded

# Check for residual modules
 grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "⚠️ 受影响模块仍在运行，需要重启" || echo "✅ 受影响模块已禁用"

If the modules cannot be removed because they are in use, a system reboot is required.

Impact of Disabling Modules

IPsec VPN solutions (StrongSwan, Libreswan, etc.)

Encrypted tunnels

Kubernetes/container networking that relies on IPsec

AFS distributed file system

Patch Status and Upgrade

CVE‑2026‑43284 upstream patch released (commit f4c50a4034e6).

CVE‑2026‑43500 patch pending confirmation.

Ubuntu security updates tracked via USN notices.

AlmaLinux and RHEL have published patches.

Upgrade Procedure

# Check and install available updates
 sudo apt update
 sudo apt full-upgrade
 # Verify kernel version
 uname -r
 # Reboot to apply new kernel
 sudo reboot

Applying a patch without rebooting leaves the old vulnerable kernel running.

Post‑Patch Cleanup

After the kernel is patched and the system rebooted, remove the temporary mitigation files:

sudo rm /etc/modprobe.d/dirty-frag.conf
 sudo update-initramfs -u -k all

Post‑Intrusion Investigation Checklist

Kernel log anomalies:

sudo journalctl -k | grep -iE 'dirty|frag|esp|rxrpc|segfault'

Suspicious login records: last -a / lastlog Temporary directory files: ls -lat /tmp /var/tmp /dev/shm New SUID files (last 7 days): find / -perm -4000 -mtime -7 2>/dev/null Abnormal su/sudo activity: sudo grep -E 'su|sudo' /var/log/auth.log SSH key modifications: find ~/.ssh -mtime -7 New cron jobs: sudo crontab -l and ls /etc/cron.d/ New system services: systemctl list-units --type=service --state=running Privileged containers:

docker ps --filter status=running --format '{{.Names}} {{.Privileged}}'

If any anomalies are found, perform a full backup, reinstall the system, and rotate all credentials, as the attacker may have left persistent backdoors.