Dirty Frag (CVE-2026-43284 + CVE-2026-43500): Local Root on Every Major Linux Distro

If you run any shared-tenant Linux box, you have work to do today. Hyunwoo Kim disclosed a Linux kernel local privilege escalation chain dubbed Dirty Frag that turns an unprivileged local user into root with a single command. It is two bugs, not one: CVE-2026-43284 in the IPsec ESP code paths (esp4 / esp6) and CVE-2026-43500 in the RxRPC subsystem. Both produce a page-cache write primitive, which is the same class of bug that made Dirty Pipe (CVE-2022-0847) and Dirty COW (CVE-2016-5195) household names. The naming is not coincidence.

Reported to Linux maintainers on April 30, 2026. An unrelated third party published the ESP exploit on May 7, 2026, breaking the embargo and forcing immediate full disclosure. The ESP fix landed in the upstream netdev tree the same day. The RxRPC fix is still pending as of the date of this post. That means many distributions are still in the gap between "the world knows about this" and "we have a vendor kernel that fixes it."

Here is what the bugs are, who is exposed, the temporary mitigations that work, and the order to apply them in.

TLDR

Detail	Info
Name	Dirty Frag
CVEs	CVE-2026-43284 (xfrm-ESP), CVE-2026-43500 (RxRPC)
Class	Page-cache write primitive, local privilege escalation
Severity	Important (Red Hat); root from any local account
Disclosed	May 7, 2026 (embargo broken)
Reporter	Hyunwoo Kim
ESP patch	Merged in upstream netdev tree May 7, 2026
RxRPC patch	Pending upstream as of May 8, 2026
Affected	Ubuntu 24.04.4, RHEL 8/9/10, AlmaLinux 8/9/10, CentOS Stream 10, Fedora 44, openSUSE Tumbleweed, OpenShift 4 (and effectively every kernel that built esp4 / esp6 / rxrpc)
Required access	Any unprivileged local account, often CAP_NET_ADMIN via user namespaces
Working PoC	Yes, public on GitHub
What you do	Apply the vendor kernel update once it ships; in the meantime, blocklist esp4, esp6, rxrpc modules and disable unprivileged user namespaces where possible

Why This One Matters

A local privilege escalation is the part of an exploit chain that turns "the attacker has a foothold" into "the attacker owns the box." On a single-user laptop the impact is mostly theoretical because the attacker who can run code as you can usually wait you out. On the systems that pay your salary, the threat model is the opposite. Anywhere a Linux kernel is shared between accounts, the LPE is the actual prize:

• CI runners. GitHub Actions self-hosted runners, GitLab runners, Jenkins agents. The job already runs as a low-privileged user. Dirty Frag promotes that to root on the runner host, which often has SSH keys, registry credentials, and access to the next-tier secret store.
• Multi-tenant Kubernetes. Pods on the same node share a kernel. A container breakout that lands you in any pod with a shell becomes a node compromise. The kubelet credentials are right there.
• Bastion / jump hosts. Most security models depend on these being trusted. An LPE on the bastion turns one compromised developer account into the entire fleet.
• Shared developer servers. Whatever your "dev box" is. Same logic.

The PoC requires nothing exotic. A user with shell access runs the binary, the chain triggers, the prompt comes back as root. Nine years of algif_aead plumbing made this much harder to spot before; now it is one git clone away from a working exploit.

What Each Bug Actually Does

Both halves of Dirty Frag are page-cache write primitives, which is what makes the "Dirty" name fit. The kernel uses the page cache to back files mmapped by user space, so a primitive that lets an unprivileged process modify pages it does not own is effectively a primitive to overwrite the contents of files the process cannot write. That is how Dirty Pipe overwrote /etc/passwd, and that is how Dirty Frag does it too.

CVE-2026-43284: xfrm-ESP page-cache write

The IPsec ESP receive path decrypts incoming packets in place. When the buffer being decrypted is a paged buffer that is not privately owned by the kernel (specifically, pages that arrived via splice(2) or sendfile(2) from a pipe), the decrypted plaintext lands in pages that user space still has a reference to. An unprivileged process can keep that reference, read out the plaintext, and write into pages backing files it would otherwise have no access to.

The bug has been latent in the ESP path since roughly 2017. It was not exploitable as a clean LPE on its own without the right kernel interfaces being reachable from user space, but CAP_NET_ADMIN inside an unprivileged user namespace provides exactly the right reach. That is why the unprivileged-user-namespace mitigation below works.

CVE-2026-43500: RxRPC page-cache write

RxRPC is the kernel implementation of the RxRPC protocol, used by AFS distributed filesystem clients. The same class of bug exists on its receive path: paged buffers that the kernel does not exclusively own end up holding plaintext that user space can read and write. RxRPC has been carrying this bug since approximately 2023, which is much narrower than the ESP timeline but still includes every long-term-support kernel of the last two years.

The chain in the public PoC uses one or both primitives depending on what the target system has loaded. ESP-only is enough on most distributions, which is why the ESP patch alone covers the worst of it.

Why "page-cache write" is so dangerous

If you have not run into this class before, the short version: a page-cache write primitive is not a memory corruption bug in the usual sense. It is a write into the kernel's view of a file's contents. Because the kernel hands those pages back to anyone who reads the file, you can drop a single byte at the right offset of /etc/sudoers, /etc/shadow, or /usr/bin/sudo and the next process that reads the file sees your version. No SMEP / SMAP / KASLR / CFI bypass needed; the primitive sidesteps the part of the kernel those mitigations protect.

Who Is Exposed

Effectively every modern Linux distribution. The vulnerable code is in the upstream kernel and the modules ship by default. Distributions explicitly named in the public advisories:

• Ubuntu 24.04.4
• Red Hat Enterprise Linux 8, 9, 10
• AlmaLinux 8, 9, 10
• CentOS Stream 10
• Fedora 44
• openSUSE Tumbleweed
• OpenShift 4

If you are running a long-term-support kernel that built esp4, esp6, or rxrpc and you do not have the vendor errata yet, assume you are vulnerable.

A few cases where exposure is reduced:

• No local users. A managed appliance with no shell account is fine for the LPE alone, since LPE needs a foothold. It is not fine if anything else lets an attacker land.
• Containers without privileged kernel reach. A container that cannot reach the esp4 / esp6 / rxrpc interfaces from user space is harder to exploit. Most production container runtimes already block raw kernel module reach, but CAP_NET_ADMIN is still common in CNI / VPN sidecars.
• Hardened kernels (grsec / Linux-Hardened) without unprivileged user namespaces. Disabling unprivileged user namespaces removes the reach for the ESP primitive on RHEL-class distros.

Cloud provider metal is at risk if you SSH into it. Cloud provider managed services (RDS, Lambda, ECS Fargate, Cloud Run) are not directly exposed because you do not have shell on the kernel; the provider does.

What to Do Today

Order matters. Do the cheap mitigations first, then watch for the vendor kernel, then patch.

1. Inventory what is loaded

# Confirm whether the vulnerable modules are loaded right now.
lsmod | grep -E '^(esp4|esp6|rxrpc)\b'

# And whether they are auto-loadable via modprobe aliases
# (this is what catches the case where the module is not loaded
#  but a user-space syscall would load it on demand).
modprobe --show-depends esp4 esp6 rxrpc 2>&1 | head -20

If lsmod shows them loaded, you are exploitable today. If they are not loaded but modprobe --show-depends finds them, an unprivileged user can still trigger the load through the same syscall paths the PoC uses.

2. Blocklist the modules where you can

This is the strongest mitigation. It also breaks IPsec VPN termination on the host and any AFS client. Use this on machines that are not IPsec VPN endpoints and do not use AFS, which is most CI runners, container hosts, and bastions:

# /etc/modprobe.d/dirty-frag.conf
blacklist esp4
blacklist esp6
blacklist rxrpc

# Force install to /bin/false so a load attempt fails fast.
install esp4  /bin/false
install esp6  /bin/false
install rxrpc /bin/false

Apply it:

# Write the file, then either reboot or unload the modules right now
# if they are currently loaded.
sudo cp dirty-frag.conf /etc/modprobe.d/dirty-frag.conf

# Unload if loaded. The order matters because of dependencies.
sudo rmmod rxrpc 2>/dev/null
sudo rmmod esp6  2>/dev/null
sudo rmmod esp4  2>/dev/null

# Confirm they are gone and will not reload.
lsmod | grep -E '^(esp4|esp6|rxrpc)\b' || echo "modules not loaded"

If you actually use IPsec on the box (Wireguard does not count, this is specifically the kernel xfrm ESP path), you cannot use this mitigation on that machine. Move to step 3.

3. Disable unprivileged user namespaces (RHEL-family)

This blocks the ESP variant on Red Hat-style kernels by removing the path through which CAP_NET_ADMIN becomes reachable to non-root users. It does not cover RxRPC, and it can break rootless containers that depend on user namespaces.

# Runtime, until reboot:
sudo sysctl -w user.max_user_namespaces=0

# Persistent across reboots:
echo "user.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/99-dirty-frag.conf
sudo sysctl --system

Validate that rootless tooling you rely on still works after this. Podman in rootless mode is the most common thing that breaks. If your CI image relies on rootless container builds, this is not the right knob.

4. Tighten local access

LPE chains need a local foothold. Things that make the foothold harder to come by are second-line defense:

• Drop SSH password authentication (PasswordAuthentication no in sshd_config).
• Run SELinux in enforcing mode where it is available.
• Run untrusted workloads as non-root and without CAP_NET_ADMIN. Audit your CI job containers; many network-tools-style images run as root for no good reason.
• On Kubernetes, push pod security to restricted for new workloads. The default baseline profile leaves CAP_NET_ADMIN reachable for some controllers.

5. Patch when the vendor kernel ships

Watch your distribution's security tracker. Once a kernel update is available, apply it and reboot. The order in which fixes ship will roughly be:

1. Mainline + stable LTS kernels (the ESP fix is already in netdev).
2. Distro kernels for current releases (Ubuntu, RHEL, Fedora, AlmaLinux are all likely to ship within days).
3. RxRPC fix once it is upstream and backported.

After patching:

# Confirm the running kernel is the patched build. The exact errata
# string varies by distro - check your distro security advisory for
# the version that includes the fix.
uname -r

# Then drop the modprobe blocklist if you put one in place,
# unless you genuinely have no use for the modules.
sudo rm /etc/modprobe.d/dirty-frag.conf

A Detection Note

There is no clean fingerprint for the exploit yet because the primitive uses normal kernel paths. A few signals that are worth alerting on:

• New userland processes that hold open AF_KEY sockets and splice() between pipes and those sockets.
• Unexpected setuid binaries created in /tmp or /var/tmp.
• Sudden modifications to /etc/passwd, /etc/shadow, /etc/sudoers, /usr/bin/sudo (you should already be alerting on these as a baseline). File integrity monitoring with auditd or osquery catches the post-exploitation step even when the exploit primitive itself is invisible.
• For Kubernetes: pods that flap in and out of Running after starting a new container that requests CAP_NET_ADMIN.

If you have an EDR product, your vendor likely has a Dirty Frag detection rule shipping in the next push. The Wiz, Tenable, and Red Hat write-ups all describe behavioral signatures.

Wrap-Up

Dirty Frag is not a sky-falling event for a single-user laptop, but it is exactly the bug pattern that ruins a quarter on multi-tenant infrastructure. The work today is short:

1. Audit which of your Linux fleet has esp4 / esp6 / rxrpc loaded.
2. Blocklist those modules everywhere you do not need IPsec and AFS.
3. Disable unprivileged user namespaces on RHEL-family hosts that need IPsec.
4. Watch your distro's tracker and roll the patched kernel as soon as it lands.

The ESP fix is upstream. Vendor kernels are the next 24-72 hours. RxRPC will trail by a few more days. Get the cheap mitigations on every machine before lunchtime and the patch can take its normal cadence.

References

• Wiz: Dirty Frag (CVE-2026-43284) Linux Privilege Escalation
• Red Hat: RHSB-2026-003 Networking subsystem Privilege Escalation
• Tenable FAQ: Dirty Frag (CVE-2026-43284, CVE-2026-43500)
• BleepingComputer: New Linux 'Dirty Frag' zero-day gives root on all major distros
• The Hacker News: Linux Kernel Dirty Frag LPE Exploit
• Help Net Security: Dirty Frag - Unpatched Linux vulnerability delivers root access
• AlmaLinux: Dirty Frag patches released
• Phoronix: Dirty Frag Vulnerability Made Public Early
• heise: "Dirty Frag" Linux flaws grant root access