Published: May 8, 2026
Risk Level: CRITICAL (affects 9+ years of kernel versions)
Status: Unpatched on most distributions; mitigations available

Executive Summary

A newly disclosed Linux kernel local privilege escalation vulnerability chain, dubbed "Dirty Frag" and assigned CVE-2026-43284 and CVE-2026-43500, enables attackers with local access to obtain root privileges by exploiting flaws in the ESP (IPsec) and RxRPC subsystems. Unlike race-condition-based exploits, this bug class is deterministic and highly reliable, similar to previous vulnerabilities like Copy Fail and Dirty Pipe.

Key facts:

• Chained for full root on every major distribution
• No race condition is required, the kernel does not panic when the exploit fails, and the success rate is very high
• Public PoC exploit available
• Independent of Copy Fail mitigations—systems with algif_aead blacklist are still vulnerable

Technical Details

The Attack Chain

Dirty Frag is a vulnerability chain combining two page-cache write primitives in the Linux kernel: one in the xfrm-ESP (IPsec) subsystem and another in RxRPC. Both flaws allow modification of page-cache-backed memory that is not exclusively owned by the kernel, enabling corruption of sensitive files and ultimately privilege escalation.

CVE-2026-43284 (xfrm-ESP Page-Cache Write): On a zero-copy send path where splice() plants a reference to a page cache page that the attacker only has read access to into the frag slot of the sender side skb, the receiver side kernel code performs in-place crypto on top of that frag. As a result, the page cache of files that an unprivileged user only has read access to (such as /etc/passwd or /usr/bin/su) is modified in RAM.

• Provides a 4-byte STORE primitive
• Present on most distributions since January 2017
• Constraint: Requires privilege to create unprivileged user namespaces (blocked on Ubuntu by AppArmor)
• CVSS 3.1: 7.8 (High)

CVE-2026-43500 (RxRPC Page-Cache Write):

• No namespace privilege required
• Present since June 2023
• Performs 8-byte pcbc(fcrypt) decrypt directly onto splice-pinned pages
• Constraint: rxrpc.ko not included by default in most distributions (but shipped on Ubuntu)
• Status: Unpatched; CVE details reserved

Why It Works on Every Distribution

xfrm-ESP Page-Cache Write provides a powerful arbitrary 4-byte STORE primitive like Copy Fail, and is included on most distributions, but it requires the privilege to create a namespace. RxRPC Page-Cache Write does not require the privilege to create a namespace, but the rxrpc.ko module itself is not included in most distributions. However, on Ubuntu, the rxrpc.ko module is loaded by default. Chaining the two variants makes the blind spots cover each other, allowing root privileges to be obtained on every major distribution.

Affected Systems

Kernel Versions

Dirty Frag affects approximately 9 years of kernel versions across major distributions. Any kernel from 2017 onwards is vulnerable.

Confirmed Affected Distributions

Also vulnerable: Any Rocky Linux, Ubuntu 22.04/20.04, Proxmox, OpenShift/Kubernetes clusters with standard kernel stacks.

Patch Status by Distribution

Latest Status (May 8, 2026)

Mitigation Strategy

Immediate Actions (Apply Now)

Option 1: Block Vulnerable Kernel Modules (Recommended)

This eliminates the attack surface entirely but requires services don't rely on ESP/RxRPC.

# Create persistent blacklist
cat > /etc/modprobe.d/dirtyfrag.conf << 'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

# Unload if already loaded
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

# Clear page cache
echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null

# Verify
sudo modprobe -n esp4 2>&1 | grep -q "Operation not permitted" && echo "✓ esp4 blocked" || echo "✗ esp4 still loadable"

⚠️ Gotchas:

• If IPsec ESP is in use, this breaks encrypted traffic
• Container runtimes (Docker, Podman) with network policies may fail
• AFS (Andrew File System) workloads will lose RxRPC support

Option 2: Disable Unprivileged User Namespaces (Partial)

Blocks xfrm-ESP but leaves RxRPC exploitable. Only viable on RHEL/CentOS if rxrpc.ko is not loaded.

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl -p /etc/sysctl.d/dirtyfrag.conf

⚠️ Impact:

• Breaks rootless containers (Docker daemon in user namespace, Podman, LXD unprivileged)
• Breaks sandboxed browsers (Firefox, Chrome sandboxes)
• Breaks Flatpak

Option 3: Access Control Hardening (Defense in Depth)

Reduce local attack surface while waiting for kernel patches:

# Restrict SSH access
echo "PermitUserEnvironment no" >> /etc/ssh/sshd_config
echo "DebianBanner no" >> /etc/ssh/sshd_config

# Disable unnecessary service accounts
usermod -s /usr/sbin/nologin nobody
usermod -s /usr/sbin/nologin ntp
usermod -s /usr/sbin/nologin mail

# Lock down cron
sudo chmod 600 /etc/crontab
sudo chmod 700 /etc/cron.d
sudo chmod 700 /etc/cron.daily /etc/cron.hourly /etc/cron.weekly /etc/cron.monthly

# Enable audit logging for privilege escalation attempts
auditctl -w /usr/bin/su -p x -k privilege_escalation
auditctl -w /usr/bin/sudo -p x -k privilege_escalation

Patching Timeline

Phase 1: Immediate (Now – May 10)

• Apply module blacklist mitigation on all systems
• Test containers/networking dependencies
• Prepare kernel update procedures

Phase 2: This Week (May 10–14)

• Deploy kernel patches as they land on your distribution
• Ubuntu: Already available
• RHEL/AlmaLinux: Expected May 9–10
• CloudLinux: Beta to stable promotion

Phase 3: Next Week (May 15+)

• Redhat distributions in stable repos
• Verify full distribution coverage

Deployment Checklist

# Ubuntu/Debian
sudo apt update
sudo apt install --only-upgrade linux-image-generic linux-headers-generic
sudo reboot

# RHEL/CentOS/AlmaLinux
sudo dnf update kernel
sudo reboot

# CloudLinux 7h/8
sudo kcarectl --update
sudo kcarectl --patch-info | grep CVE-2026-43284

# Proxmox (Debian-based)
sudo apt update && sudo apt dist-upgrade
sudo pve-efi-boot-guard --force && sudo reboot

Monitoring & Detection

Detect Active Exploitation Attempts

# Watch for ESP/RxRPC module load attempts (if blacklisted)
auditctl -w /lib/modules -p x -k dirty_frag_load_attempt

# Monitor for splice syscall abuse patterns
auditctl -S splice -S sendfile -S vmsplice -k zero_copy_abuse

# Log namespace creation
auditctl -S unshare -S clone -k namespace_creation
auditctl -F auid>=1000 -F auid!=-1 -S clone -S unshare -k user_namespace

EDR/XDR Detection

# Example Wazuh rule
<rule id="100001" level="10">
  <if_sid>4101, 4102</if_sid>
  <field name="audit.syscall">splice|sendfile|vmsplice</field>
  <field name="audit.auid" operator="!">^(root|-1)$</field>
  <description>Possible Dirty Frag exploit attempt</description>
</rule>

Monitor for:

• Unprivileged splice/sendfile syscalls (unusual volume)
• Failed modprobe attempts (if blacklist applied)
• /proc/sys/vm/drop_caches modifications from non-root
• Unusual file permission modifications to system binaries

Impact on Running Services

Safe to Apply Module Blacklist

• Mail servers (Postfix, Exim, OpenSMTPD)
• Web servers (Nginx, Apache, OpenLiteSpeed)
• Databases (MySQL, PostgreSQL, MongoDB)
• DNS servers (BIND, PowerDNS)
• Standard container workloads

Risky to Apply Module Blacklist

• IPsec VPN endpoints (disable if possible, use WireGuard/OpenVPN instead)
• AFS clients (rare in production)
• Rootless Docker/Podman (use module blacklist only, not namespace disable)
• OpenShift on non-hardened clusters (wait for official advisories)

Hardening Recommendations (Post-Patch)

1. Implement strict CAP_SYS_ADMIN dropping in container runtimes.
2. Monitor for kernel version drift in Proxmox/cluster environments.

Lock down unprivileged namespaces if feasible:

echo "kernel.unprivileged_userns_clone=0" | sudo tee /etc/sysctl.d/hardening.conf

Enable LSM hardening:

echo "lsm=landlock,lockdown,yama,integrity,apparmor,selinux" | sudo tee -a /etc/default/grub
sudo update-grub && sudo reboot

Distribution-Specific Notes

Ubuntu

The affected components are Linux kernel modules. The first vulnerability impacts the modules that provide support for ESP (Encapsulating Security Protocol), one of the protocols used for IPsec (Internet Protocol Security). The second vulnerability impacts the modules that provide support for RxRPC, a protocol used for AFS (Andrew File System), a distributed file system. The vulnerabilities affect multiple Linux distributions, including all Ubuntu releases.

Status: Patches already available. Standard apt upgrade covers both CVEs.

CentOS / RHEL / AlmaLinux

For environments where IPsec must remain functional, the ESP variant (CVE-2026-43284) can be blocked by disabling unprivileged user namespaces. Warning: This only blocks the ESP variant. On RHEL 9 and 10, the rxrpc variant (CVE-2026-43500) remains exploitable unless rxrpc is also blocklisted. Disabling unprivileged user namespaces may also affect rootless containers, sandboxed browsers, and Flatpak.

Tracking: RHSB-2026-003. Monitor Red Hat security portal for updates.

CloudLinux

A working public proof-of-concept exists; any unprivileged local user can use it to gain root in a single command. The flaw is in the in-place decryption path of esp4, esp6, and rxrpc. CloudLinux released patches to beta channel on May 8; expect stable by May 10.

Update path: kcarectl --update with KernelCare.

Debian

Debian: https://security-tracker.debian.org/tracker/CVE-2026-43284 and https://security-tracker.debian.org/tracker/CVE-2026-43500

Track the security tracker linked above for DSA release.

What You Should Do Today

1. Apply mitigation: Use Option 1 (module blacklist) unless you depend on ESP/RxRPC.
2. Test and monitor: Verify containers/services work post-mitigation, enable audit logging.
3. Queue kernel patch: Schedule maintenance window this week for kernel upgrade.
4. Update documentation: Note the vulnerability and applied mitigation in your runbooks.

Assess exposure:

# Check kernel version
uname -r

# Check if vulnerable modules are loaded
lsmod | grep -E "esp|rxrpc"

# Check if unshare is available (namespace creation)
grep -i "user_namespaces" /boot/config-$(uname -r)

References

• Wiz Blog: Dirty Frag vulnerability analysis
• Red Hat RHSB-2026-003 Security Advisory
• CloudLinux Dirty Frag mitigation and updates
• Ubuntu Dirty Frag fixes announcement
• Official PoC: https://github.com/V4bel/dirtyfrag
• Technical writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md

Last Updated: May 8, 2026, 18:00 UTC
Status: Patched kernels rolling out; mitigation effective immediately.