Dirty Frag (CVE-2026-43284): Linux Kernel LPE — blacklist the modules, weigh IPsec, protect customer stacks

A newly disclosed Linux kernel vulnerability called Dirty Frag (CVE-2026-43284) lets unprivileged users gain full root access to the host in short order — a universal local privilege escalation. Every Linux version since 2017 is affected, including kernel 7.0.4. Until the patch arrives, the recommended mitigation is to blacklist three vulnerable kernel modules (esp4, esp6, rxrpc) via /etc/modprobe.d/dirtyfrag.conf and unload them with rmmod if already loaded — AWS additionally recommends ipcomp4 and ipcomp6 as defence in depth. Trade-off: IPsec and the kAFS variant of the AFS filesystem will break, OpenAFS is unaffected. For mid-market customer stacks this means a week of work: inventory of Linux hosts, check who runs IPsec or kAFS, mitigation in non-critical waves, closure with the kernel patch as soon as the distribution ships it. Eighth trust/CVE post in our cluster, in direct line to Copy Fail (early May 2026).

What the vulnerability is

Dirty Frag (CVE-2026-43284) has been officially tracked since 8 May 2026 (CVE ID first published by AlmaLinux). The UMich Information Assurance advisory of 7 May 2026 describes it as a universal Linux LPE: a local user without elevated rights can become root in short order. The public proof of concept is at github.com/V4bel/dirtyfrag.

According to UMich, every Linux version released since 2017 is affected, including kernel 7.0.4. The reach is unusually broad — comparable to Copy Fail, which we discussed in the cluster in early May (CVE-2026-31431). Comparable not in technical detail, but in consequence: every Linux host that isn't mitigated or patched is now a one-step target for local escalation.

The oss-security disclosure of 7 May 2026 provides the technical anatomy: Dirty Frag is a chain of two separate page-cache write flaws — one in xfrm-ESP (IPsec fast path with MSG_SPLICE_PAGES no-COW) and one in RxRPC (the kAFS transport layer). The chain becomes reachable via the XFRM user netlink interface, which auto-loads the relevant kernel modules on demand. That's why the mitigation targets exactly these three modules (esp4, esp6, rxrpc) — they are the entry door to the chain, even on hosts that don't actively use IPsec or kAFS themselves.

Confirmed affected per oss-security and follow-up distribution advisories: Ubuntu 24.04.4, RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, openSUSE Tumbleweed — every mainstream distribution running current kernels up to 7.0.x. For the DACH mid-market stack: practically every Linux box in default setup is affected, regardless of distribution choice.

The disclosure was uncoordinated: the linux-distros embargo was set for 12 May 2026, but a third party published the ESP component prematurely on 7 May, which forced the researcher into immediate full disclosure. That's why patches were not ready and CVE IDs not assigned at public disclosure — and why the module blacklist mitigation is the only available defence in the first few days.

Patch status as of 8 May 2026 (asymmetric): the ESP-component patch (mainline commit f4c50a4034e6, SKBFL_SHARED_FRAG flag fix) was merged into the netdev tree on 7 May. The RxRPC-component patch is still unmerged upstream as of now. For distribution kernel packages this means a phase with partial patches — the module blacklist mitigation stays the consistent defence until both components land in their respective distribution kernels. Vulnerability history for the audit answer: ESP since January 2017 (cac2661c53f3), RxRPC since June 2023.

Who can attack — and why LPE matters in mid-market

LPE vulnerabilities aren't a server-only topic. Three scenarios where Dirty Frag bites mid-market organisations directly:

• Developer / CI machines with shared accounts. Anyone running build runners, jump hosts, or test VMs with multiple users now has an escalation line between standard user and root that shouldn't exist.
• Container hosts with tenant isolation. If a workload runs at lower privilege (the rule in a clean Kubernetes setup), Dirty Frag breaks that isolation. Container escapes via kernel LPE are textbook.
• Web servers with a compromised application. An app that itself only runs as www-data or similar gets, with Dirty Frag, the lever to take full host control — even on systems whose discipline was precisely to keep applications unprivileged.

The universal reach (every kernel since 2017) means: practically every production Linux host in the mid-market is affected today, unless the mitigation or the future patch has already been applied.

Mitigation, the way UMich recommends it

The mitigation works by blocking the three vulnerable kernel modules (esp4, esp6, rxrpc). Three immediate steps:

1. Create the file /etc/modprobe.d/dirtyfrag.conf with these three lines:
   install esp4  /bin/false
install esp6  /bin/false
install rxrpc /bin/false
2. Check whether the modules are currently loaded: lsmod | egrep '^(esp4|esp6|rxrpc)'
3. If loaded, unload: rmmod esp4 / rmmod esp6 / rmmod rxrpc

That prevents the vulnerable modules from loading on next boot and removes them from the running kernel immediately.

AWS note: two additional modules to block. The AWS Security Bulletin AWS-2026-027 recommends blacklisting ipcomp4 and ipcomp6 (IP-compression modules) in addition to the three UMich modules. The extra two aren't directly part of the chain, but they belong to the same xfrm module family and auto-load through the same netlink path — defence in depth against auto-load vectors that could become usable in a follow-up exploit. Plus two flanking steps: disable creation of unprivileged user namespaces (user+net) via sysctl, and tighten monitoring for anomalous setuid executions. For Amazon Linux hosts that broader list is the official recommendation; on other distributions it makes sense as a clean defence-in-depth variant.

Mitigation on NixOS — the declarative variant

On NixOS, /etc/modprobe.d/ is a symlink into the Nix store — manual edits get wiped on the next nixos-rebuild. The correct path is via the NixOS configuration:

{ pkgs, ... }:
{
  boot.extraModprobeConfig = ''
    install esp4 ${pkgs.coreutils}/bin/false
    install esp6 ${pkgs.coreutils}/bin/false
    install rxrpc ${pkgs.coreutils}/bin/false
  '';

  boot.blacklistedKernelModules = [ "esp4" "esp6" "rxrpc" ];
}

Three properties NixOS handles better than the classic distribution variant:

• Path correctness. On NixOS, /bin/false doesn't exist — the Nix-store path ${pkgs.coreutils}/bin/false is the only one that actually takes effect after nixos-rebuild. The UMich procedure copy-pasted 1:1 means errors in the modprobe log on NixOS, not mitigation.
• Atomic and rollback-able. After sudo nixos-rebuild switch the mitigation is part of the current system generation. When the distribution patch arrives, just remove the block from the config and rebuild. If anything breaks: sudo nixos-rebuild --rollback switch. No forgotten dirtyfrag.conf files that linger on a host indefinitely.
• Declarative multi-host rollout. Via deploy-rs, colmena, NixOps, or simply nixos-rebuild --target-host, the configuration rolls out across every declared host in one wave. The audit answer to “which host carries the mitigation, which doesn't?” is a Git question, not a sampling question.

Removing currently loaded modules still works the classic way via sudo rmmod esp4 esp6 rxrpc — that's generic Linux, independent of the distribution pattern.

Trade-offs of the mitigation — what breaks

IPsec. The modules esp4 and esp6 are part of the IPsec infrastructure for IPv4 and IPv6. Anyone running site-to-site VPNs or host-to-host IPsec loses the ESP path with the mitigation. Where IPsec is in production use, alternative connectivity has to be in place before the mitigation, or the application has to be briefly interrupted.

kAFS. The rxrpc module is the transport layer of the kernel AFS implementation. Anyone running kAFS in production loses filesystem access. The OpenAFS implementation is explicitly not affected by the mitigation — in mid-market that's also the more common case.

UMich gives a clear caution: on systems where the modules are already loaded, the mitigation should be tested on non-critical systems first before being rolled out to production. That's standard discipline and applies all the more to anything touching IPsec or AFS in any form.

How we handle this ourselves

A recommendation without our own practical experience is hollow advice. We use what we build.

When the UMich advisory landed on 7 May, we ran the same pattern internally as we did for Copy Fail: SBOM diff across all customer stacks, every Linux host with a kernel from 2017 onwards (i.e. essentially all of them) marked as affected, IPsec and kAFS usage checked per stack. Most customer stacks have neither IPsec in the kernel stack (site-to-site tunnels run via WireGuard or dedicated VPN appliances) nor kAFS (OpenAFS is the rare standard in DACH mid-market, kAFS rarer still). That makes the mitigation low-risk for most stacks. The few special cases run through the established wave: non-critical pre-prod first, then staging, then production in a defined maintenance window.

In our own stack: mitigation on non-critical build runners and test VMs / test VPS during the day on 8 May, production hosts on 8 May. The kernel patch will be installed as soon as the distribution (Debian-stable, Ubuntu LTS, RHEL family) ships it through the usual channels; that's the moment the mitigation can be rolled back.

Three depths of action for your stack

Short-term (today or tomorrow):

• Linux host inventory: which machines run a kernel from 2017 onwards? Practically all. Make a list, ordered by criticality.
• IPsec / kAFS check per host: ip xfrm state for IPsec, lsmod | grep -E 'kafs|rxrpc' for kAFS. Most mid-market stacks are clean on both.
• Roll out the mitigation on non-critical hosts, run lsmod check, rmmod if needed.

Medium-term (next 2 weeks):

• Roll out the mitigation on production hosts, in planned maintenance windows. For hosts with IPsec: alternative connectivity or short downtime planned.
• Distribution watch: install the kernel patch as soon as it lands in Debian/Ubuntu/RHEL streams. Mitigation can then be rolled back if IPsec needs to come back online.
• Audit trail: document which host was mitigated/patched when. Precondition for the CRA reporting path from September 2026 being credible.

Strategic (next quarter):

• If your running SBOM didn't give you clarity on affected hosts within hours this time, that's an indicator: SBOM routine beats improvisation when the next universal LPE comes. And it will.
• Re-evaluate IPsec strategy: anyone running IPsec via kernel modules today should check whether WireGuard or a dedicated VPN appliance would be the more robust variant. Not because of Dirty Frag specifically, but because that layer is regularly in the crosshairs.
• Patch pipeline tempo: can your pipeline ship a critical kernel patch in 7 days without hero mode? If not, that's the strategic gap that becomes visible between the lines here.