Dirty Frag: Unpatched Linux LPE with Live PoC, Free Worklet Available

On May 7, security researcher Hyunwoo Kim published a working proof-of-concept for a Linux kernel local privilege escalation chain called Dirty Frag. The disclosure happened earlier than planned after a third party broke the embargo, meaning distribution backports were not in place when the PoC went public.

What it is

Dirty Frag chains two kernel flaws to reach root on virtually every major Linux distribution:

  • CVE-2026-43284 (xfrm-ESP Page-Cache Write): Patched in mainline, but distribution backports are still pending
  • CVE-2026-43500 (RxRPC Page-Cache Write): No patch in any tree at time of writing

Confirmed affected distros include Ubuntu 24.04.4, RHEL 10.1, AlmaLinux 10, CentOS Stream 10, openSUSE Tumbleweed, and Fedora 44. The ESP flaw has been present in the kernel since January 2017. The RxRPC flaw since June 2023.

Important: the Copy Fail mitigation does not cover this

If your team blocked algif_aead after CVE-2026-31431, you are not protected from Dirty Frag. The two are related in bug class but the existing mitigation does not stop this chain.

What to do now

Block and unload the five affected kernel modules: esp4, esp6, ipcomp4, ipcomp6, and rxrpc. Note that unloading these breaks IPsec VPN tunnels, IPComp, and RxRPC-dependent workloads, so evaluate per host before deploying broadly. If a module is in active use, the unload will be deferred and the endpoint flagged for reboot.

Additional hardening steps from the blog:

  • Restrict unprivileged user namespace creation with sysctl -w user.max_user_namespaces=0 on hosts that do not need it (note this can break rootless containers, Snap, and some browser sandboxes)
  • If modules are not currently loaded, prevent future loading with sysctl -w kernel.modules_disabled=1 to lock the module set until next reboot
  • Apply distribution backports for CVE-2026-43284 as soon as they land and track CVE-2026-43500 separately until an upstream fix exists

Detection

  • Monitor for anomalous add_key("rxrpc", ...) and XFRMA_REPLAY_ESN_VAL netlink calls, both are unusual in normal workloads
  • Watch for anomalous setuid execution, such as an unprivileged process launching a root shell
  • Run lsmod | grep -E "esp4|esp6|ipcomp4|ipcomp6|rxrpc" across your fleet to inventory loaded modules
  • If you suspect an endpoint was exploited before remediation, drop the page cache or reboot before trusting it

What the Worklet does not cover

The Worklet blocks and unloads the affected modules. It does not patch the kernel, apply the namespace or modules-disabled sysctl knobs, drop the page cache, or perform behavioral detection of prior exploitation. Those steps require manual evaluation per host.

The Worklet

Automox has published a free Worklet that automates the module-blocking mitigation across managed Linux endpoints. The source is open on GitHub whether you are an Automox customer or not.

Full technical breakdown from Automox CTO Jason Kikta, including how the exploit works and what the Worklet does and does not cover: https://www.automox.com/blog/dirty-frag-what-you-need-to-know-and-how-to-respond

Posted May 8, 2026, 3:46 PM UTC

10
Loading comments…