Dirty Frag (CVE-2026-43500) — Linux Kernel RxRPC Root Escalation, Public Exploit Out

Dirty Frag (CVE-2026-43500) — Public Exploit Out, Patch Now

A new Linux kernel local privilege escalation called Dirty Frag was publicly disclosed on May 7, 2026, ahead of the coordinated embargo schedule. The vulnerability is tracked as CVE-2026-43500 for the RxRPC half and CVE-2026-43284 for the matching IPsec ESP half — together they form a chained bug class that lets any local unprivileged user reach root through the kernel's in-place network decryption path. A working exploit is already public.

Almost every major Linux distribution is affected, going back several kernel releases. Patched kernels are rolling out now. Anyone running Linux on a server, container host, or workstation should treat this as urgent maintenance work. If you cannot patch and reboot today, there is a non-disruptive module-level mitigation below that closes the attack surface in under a minute.

This article focuses on CVE-2026-43500 (the RxRPC variant) because RxRPC ships enabled by default on far more distributions than IPsec ESP requires it. Both CVEs share the same root cause and the same fix — the mitigation block at the end covers all three vulnerable modules.

What the Bug Actually Is

The Linux kernel exposes several protocols that can perform cryptographic operations in-place over user-supplied memory — historically a performance optimisation that avoids extra allocations on the receive path. The pattern looks innocent in isolation: the kernel takes a socket buffer carrying paged fragments, decrypts them where they sit, and returns the plaintext to userspace.

The defect is that the kernel does not verify who actually owns those pages. When the fragments arriving on the receive path are not privately owned by the kernel — for example, pipe pages attached via splice(2), sendfile(2), or the newer MSG_SPLICE_PAGES mechanism — the in-place decryption writes its output back into pages that may be shared with the userspace page cache. The kernel cheerfully decrypts attacker-controlled ciphertext into pages it does not own.

This is the same class of bug as Dirty Pipe (CVE-2022-0847), but more general and more reliable. Dirty Pipe relied on a narrow race condition in pipe buffer flag handling. Dirty Frag is a deterministic logic flaw — no race, no panics, high success rate on the first attempt. The exploit fits in a small amount of code and targets cached binaries directly.

How the RxRPC Exploit Works

The published exploit follows a five-step path. None of the steps require special privileges; every primitive is reachable from a normal user account on a default-configured kernel.

1. Create an AF_RXRPC socket
   socket(AF_RXRPC, SOCK_DGRAM, PF_INET)

2. Register a kernel rxkad key
   add_key("rxrpc", ...)

3. vmsplice() a page from the cache of a privileged binary
   target = /usr/bin/su (read into page cache via cat)
   vmsplice(pipefd, ..., SPLICE_F_GIFT)

4. splice() crafted RxRPC datagrams through the borrowed page
   splice(pipefd_in, ..., rxrpc_fd_out, ...)

5. The kernel decrypts in place. The plaintext is the attacker's
   payload. It is written into the page cache copy of /usr/bin/su.

Once the cached copy of /usr/bin/su is corrupted in memory, the next execve(/usr/bin/su) runs the attacker's modified binary instead of the one on disk. The file on disk is untouched. Its inode is unchanged. Its checksum is unchanged. Only the in-memory representation that the kernel hands to execve has been silently rewritten.

The RxRPC variant of the fast-path pattern was introduced in June 2023. The defect has been in shipped kernels for roughly two years.

Who Is Affected

Most Linux distributions shipping kernels released since mid-2023 are exposed. Confirmed vulnerable lines include:

• Ubuntu 22.04 and 24.04 LTS — patched kernels available via the Ubuntu security tracker for CVE-2026-43500.
• AlmaLinux 9 and 10 when the kernel-modules-partner package is installed; AlmaLinux 8 is unaffected for this CVE.
• Red Hat Enterprise Linux 9 and 10 — vendor advisory published with patched kernel packages.
• Debian, Fedora, Arch, openSUSE — patched kernels available through normal package channels.
• CloudLinux — patched kernels published on production repositories without requiring the testing channel.

Exposure is local privilege escalation. The bug does not provide remote code execution on its own. An attacker needs an unprivileged shell, a service account, a CI runner, a Kubernetes pod with a writable filesystem, or any other foothold on the system. Once they have that, Dirty Frag closes the gap to root in seconds.

In container environments the picture is sharper. The AF_RXRPC socket family is reachable from inside most default container configurations, and Docker's default seccomp profile does not block socket(AF_RXRPC, ...) on all kernel versions. A privilege escalation inside any container becomes a privilege escalation on the host kernel, which is shared by every container on the node. Multi-tenant Kubernetes clusters, GitLab Runners, GitHub Actions self-hosted runners, and any platform that executes untrusted code at the container layer should treat this as a node-level emergency.

The 30-Minute Patch Plan

For most teams the right plan is straightforward and finishes inside a single maintenance window per server.

1. Identify exposed hosts

# Check running kernel
uname -r

# Check whether the rxrpc module is loaded
lsmod | grep -E 'rxrpc|esp4|esp6'

# Confirm package version
dpkg -l linux-image-\$(uname -r)            # Debian/Ubuntu
rpm -qa | grep kernel                       # RHEL/Alma/Rocky/Fedora

2. Apply the vendor patch

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

# RHEL / AlmaLinux / Rocky / Amazon Linux
sudo dnf update kernel
sudo reboot

# SUSE
sudo zypper patch --category security
sudo reboot

# Arch (rolling)
sudo pacman -Syu
sudo reboot

3. Verify the patched kernel is actually running

# AlmaLinux 9 minimum
rpm -q kernel | grep -E '5\\.14\\.0-611\\.54\\.3\\.el9_7|higher'

# AlmaLinux 10 minimum
rpm -q kernel | grep -E '6\\.12\\.0-124\\.55\\.2\\.el10_1|higher'

# Ubuntu 24.04 — confirm via security tracker
apt-cache policy linux-image-generic

A common failure mode is "we ran apt upgrade so we are fine" while the running kernel is still the old one because no reboot happened. uname -r is the source of truth. The package version is irrelevant if the system never booted the new kernel.

4. Drop the page cache after reboot

After patching and rebooting, drop the in-memory page cache so that any pre-existing corrupted entries from before the patch are evicted:

sudo sync
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

This step is cheap and worth running even on hosts you patched proactively before any attempt was made.

Temporary Mitigation If You Cannot Reboot Yet

If a reboot is not possible immediately — for example a system mid-batch-job or under a hard freeze — the three vulnerable kernel modules can be blocked at the module level without disrupting most workloads. This is the AlmaLinux-published workaround, also confirmed by CloudLinux and Sysdig:

sudo sh -c "printf 'install esp4 /bin/false\\ninstall esp6 /bin/false\\ninstall rxrpc /bin/false\\n' \\
  > /etc/modprobe.d/dirtyfrag.conf"

sudo rmmod rxrpc esp4 esp6 2>/dev/null || true

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

The install ... /bin/false line prevents the module from being loaded again until the modprobe.d file is removed. The rmmod line unloads the module if it is currently loaded. The drop_caches line evicts any pre-existing corrupted page cache entries.

The mitigation is non-disruptive for the vast majority of production workloads. RxRPC is used primarily by Andrew File System (AFS) clients and servers — if your environment is not running AFS, you are not using RxRPC. IPsec ESP (esp4/esp6) is used by IPsec tunnels and most strongSwan/Libreswan configurations; if you terminate IPsec at a router or appliance and not on the Linux host, the modules can be safely blocked. Standard TLS, SSH, dm-crypt and LUKS, kTLS, OpenSSL, and GnuTLS do not depend on the vulnerable modules and remain unaffected.

To verify the mitigation took effect:

lsmod | grep -E 'rxrpc|esp4|esp6'
# (should return nothing)

modprobe rxrpc 2>&1
# modprobe: ERROR: ...

The mitigation is a stopgap. Schedule the full kernel patch and reboot in the next available maintenance window even with the workaround in place.

Detection Rules

Sysdig published a Falco rule that fires on any process creating an AF_RXRPC socket outside of a known-good AFS daemon. This is a high-signal detection because AF_RXRPC sockets have almost no legitimate use outside AFS environments.

- rule: Unexpected AF_RXRPC socket creation
  desc: >
    Detects creation of an AF_RXRPC (RxRPC protocol, domain 33) socket
    by a process that is not a known AFS client or server daemon.
    AF_RXRPC sockets are rarely used outside of AFS; unexpected creation
    may indicate exploitation of CVE-2026-43500 (Dirty Frag).
  condition: >
    evt.type = socket and evt.dir = >
    and evt.arg.domain = AF_RXRPC
    and not proc.name in (afsd, rxgen, fileserver)
  output: >
    AF_RXRPC socket created (proc=%proc.name pid=%proc.pid
    user=%user.name cmdline=%proc.cmdline)
  priority: WARNING
  tags: [linux, kernel, cve-2026-43500, dirty-frag]

For environments without Falco, an equivalent eBPF-based check can be added to existing audit tooling, or auditd can be configured to log all socket syscalls with domain 33 (AF_RXRPC) and alert on hits.

Verification After Patching

To confirm that the running kernel includes the fix and is not vulnerable, the simplest test is to combine a kernel version check with a runtime probe:

# Running kernel
uname -r

# Confirm rxrpc is either patched (loaded with new version) or absent
modinfo rxrpc 2>/dev/null | head -5

# Confirm modprobe block (if mitigation is in place instead of patch)
cat /etc/modprobe.d/dirtyfrag.conf 2>/dev/null

# Confirm page cache was dropped at least once since the fix landed
journalctl --since '7 days ago' | grep -i 'drop_caches\\|dirtyfrag' || \\
  echo 'No drop_caches recorded recently — consider running it once.'

For larger fleets, drive the verification from your configuration management or observability stack. Node Exporter publishes the running kernel version through the node_uname_info metric; a Prometheus alert on "any host whose kernel version is below the published patched version for its distribution" turns Dirty Frag into a tracked compliance check rather than a one-off scramble.

What This Disclosure Should Change

The proximate fix for Dirty Frag is a package update, a reboot, and a page-cache flush. The longer-term lesson, and it is now becoming a pattern across 2026 kernel disclosures (Copy Fail, Dirty Frag, and others to come), is that in-place cryptographic optimisations on networking and crypto fast-paths sit inside the kernel for years before someone notices that the receive-side memory they operate on may not be owned by the kernel.

If your fleet is missing any of these defences, treat Dirty Frag as the prompt to add them:

• Run a tight default seccomp profile on every container runtime — denying socket families that the workload does not use, including AF_RXRPC and AF_ALG.
• Use rootless containers or user namespaces wherever the workload supports them, so container root is not host root.
• Disable kernel modules that no application on the host actually needs, and audit which modules are loaded versus which are required.
• Subscribe every host to a managed kernel patch feed with automated reboots scheduled inside a defined maintenance window per environment. The time between disclosure and full fleet remediation should be measured in hours, not days.
• For multi-tenant platforms, accept that a shared kernel is shared trust. Microvm isolation (Firecracker, Kata Containers) or per-tenant nodes are the only architectural answers to this class of risk.

Reference

Dirty Frag is tracked publicly as CVE-2026-43500 (RxRPC) and CVE-2026-43284 (IPsec ESP). The AlmaLinux, CloudLinux, Ubuntu, Red Hat, and SUSE security advisories publish vendor-specific patch details. Sysdig and Tenable have published technical write-ups and runtime detection rules. The patched kernel and a reboot remain the only fully complete remedy; the modprobe block plus a drop_caches flush is the recommended interim mitigation.