Dirty Frag: Unpatched Linux LPE, Homelab Mitigations

Dirty Frag mitigation without a patched kernel: block the esp4, esp6 and rxrpc modules, why restricting user namespaces is not enough, and what the stopgap breaks.

Terminal window showing a Linux kernel vulnerability exploit chain with privilege escalation output

Dirty Frag was published on 7 May 2026 with a working exploit and, at that moment, no patches and no CVEs: the embargo had broken. It’s a local root exploit that chains two kernel bugs, CVE-2026-43284 (IPsec ESP: esp4/esp6) and CVE-2026-43500 (RxRPC: rxrpc). Fixed kernels have since been released (see the patch guide). This page covers the window before you can install one.

The mitigation that works: block the modules

The disclosure itself gives the stopgap: prevent the three modules from loading and unload them if they’re loaded.

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

Check that none are loaded afterwards:

grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || echo "none loaded"

If one won’t unload because it’s in use, reboot. The modprobe file keeps it from loading again.

What it breaks

  • Kernel IPsec using ESP: strongSwan or Libreswan tunnels that use the kernel’s ESP stack.
  • RxRPC: mainly the in-kernel AFS client.

WireGuard, Tailscale and OpenVPN don’t use these modules. Most homelabs lose nothing.

Why restricting user namespaces is not enough

Restricting unprivileged user namespaces is often suggested for kernel LPEs, and it does stop the ESP half: that path needs the networking privileges a user namespace provides. But the RxRPC half doesn’t. According to Sysdig’s analysis, on Ubuntu, where user namespaces are restricted by default but rxrpc.ko ships in the standard kernel package, the exploit simply uses RxRPC. Block the modules.

Reduce who can run code

Like any local exploit, Dirty Frag needs code execution first:

  • Remove or lock shell accounts that don’t need access: sudo usermod -L username
  • Don’t run untrusted containers or images on hosts you care about. LXC containers share the host kernel.
  • Keep internet-facing services updated, since a compromised service is the usual first foothold.

Then patch

The module block is temporary. Once your distribution ships the fixed kernel, install it, reboot, and delete /etc/modprobe.d/dirtyfrag.conf if you need IPsec or AFS back.

Sources: the oss-security disclosure, the CVE records for CVE-2026-43284 and CVE-2026-43500, and Sysdig’s analysis.

What’s Next

Frequently Asked Questions

Does disabling unprivileged user namespaces stop Dirty Frag?
No. It blocks the ESP variant, but the RxRPC variant doesn't need user namespaces. Sysdig notes that on Ubuntu, where user namespaces are restricted but rxrpc.ko ships by default, the exploit uses the RxRPC path.
What breaks if I block esp4, esp6 and rxrpc?
Kernel IPsec using ESP, such as strongSwan or Libreswan tunnels, and anything using RxRPC, mainly the in-kernel AFS client. WireGuard and OpenVPN don't use these modules.
Do I still need to patch after blocking the modules?
Yes. The module block is a stopgap. Install the fixed kernel, reboot, and then remove the modprobe file if you need IPsec or AFS.

Get notified when new articles and designs land:

No spam. Unsubscribe any time.

Sergej Voronko
Sergej Voronko
SAP Basis · Senior Operations Manager · Linux infrastructure engineer
About the author →

[discussion]

Comments are powered by Giscus — backed by GitHub Discussions. Sign in with GitHub to join the conversation.