Block Dirty Frag Kernel Modules on Linux Endpoints

What the Dirty Frag mitigation Worklet does

This Automox Worklet™ blocks the Linux Dirty Frag local privilege escalation chain by disabling the kernel modules that the exploit relies on. The Worklet writes a modprobe blacklist file at /etc/modprobe.d/dirty-frag-mitigation.conf that prevents the esp4, esp6, ipcomp4, ipcomp6, and rxrpc modules from loading, then unloads each module from the running kernel with modprobe -r. After remediation, the exploit chain has no usable surface even if a vulnerable kernel is still booted on the endpoint.

Dirty Frag is a two-CVE chain. CVE-2026-43284 is a use-after-free in the xfrm-ESP packet path; CVE-2026-43500 is a memory corruption in the RxRPC subsystem. Either bug on its own is exploitable; the chain combines them for a reliable local root. Disabling the underlying modules cuts off both halves of the chain at the same time, which is why this Worklet blocks five modules rather than just the two that contain the bugs.

The blocked modules are not optional features the average Linux endpoint relies on. ESP and IP-Compression are IPsec components used by some VPN configurations; RxRPC is the transport for the AFS distributed filesystem. Most fleets do not use either. The Worklet calls this out explicitly in the activity log so the operations team can verify the dependency profile before approving the rollout across IPsec gateways or AFS clients, where the trade-off matters.

Why block Dirty Frag modules across the fleet

A local privilege escalation chain separates a contained credential compromise from a full host takeover. When an attacker lands on a Linux endpoint through a phished user account or a vulnerable web application, the next move is to escalate to root so they can install persistence, dump credentials, or pivot. Dirty Frag is an easy escalation because it lives in modules that most distributions auto-load and few admins audit. The window between the public disclosure and a vendor kernel patch is the exposure surface.

Deploying the module block fleet-wide collapses the exposure window from weeks to a single policy run. A vendor kernel for CVE-2026-43284 and CVE-2026-43500 typically lands one to three weeks after public disclosure, then has to be regression-tested against your hardware, scheduled into a maintenance window, and rebooted into. The modprobe blacklist removes the exploitable code path in seconds and survives every reboot until you retire it. Pair this Worklet with a kernel update policy that removes /etc/modprobe.d/dirty-frag-mitigation.conf once the patched kernel is rolled out, and the fleet returns to its native IPsec and RxRPC capability without manual cleanup.

How the Dirty Frag mitigation works

1. Evaluation phase: The Worklet runs lsmod and grep -E '^(esp4|esp6|ipcomp4|ipcomp6|rxrpc) ' to see whether any of the five target modules are currently loaded. It also grep -Rs the /etc/modprobe.d/ directory for an install or blacklist directive covering each module. If any module is loaded or any blacklist entry is missing, the endpoint is flagged for remediation. Endpoints already fully mitigated are reported compliant and skipped.

2. Remediation phase: The remediation script writes /etc/modprobe.d/dirty-frag-mitigation.conf with install esp4 /bin/true, install esp6 /bin/true, install ipcomp4 /bin/true, install ipcomp6 /bin/true, and install rxrpc /bin/true. It then runs modprobe -r esp4 esp6 ipcomp4 ipcomp6 rxrpc to unload each module from the live kernel. Exit 0 on success or non-zero with the offending module name in stderr if a module is in use by a mounted resource or an active VPN tunnel.

Dirty Frag mitigation requirements

• Linux endpoint running kernel 5.x or 6.x with modprobe and the standard /etc/modprobe.d/ load path

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• Confirmation that the endpoint does not depend on IPsec ESP, IPsec IP-Compression, or RxRPC for production network paths; for VPN gateways and AFS clients, exclude those endpoints from the policy scope and rely on the kernel update path instead

• A follow-up kernel update policy that ships the patched kernel for your distribution; the mitigation Worklet is intended as a stop-gap, not a permanent fix

• Documented rollback procedure (rm /etc/modprobe.d/dirty-frag-mitigation.conf followed by modprobe esp4 esp6 ipcomp4 ipcomp6 rxrpc) for endpoints where the trade-off becomes unacceptable

Expected kernel module state after mitigation

After successful remediation, the file /etc/modprobe.d/dirty-frag-mitigation.conf exists on the endpoint with all five install directives, and lsmod returns no rows for esp4, esp6, ipcomp4, ipcomp6, or rxrpc. The Dirty Frag exploit chain has no kernel surface to attack even if the running kernel still contains the underlying bugs. Subsequent Automox policy runs report the endpoint as compliant without applying remediation again.

Validate by running modprobe esp4 on a remediated endpoint and confirming the command exits silently without loading the module (because the install directive points the loader at /bin/true). For audit evidence, capture the contents of /etc/modprobe.d/dirty-frag-mitigation.conf and the lsmod output, then store them with the policy run identifier. Once the patched kernel is in place across the fleet, retire this Worklet by removing the conf file via a follow-up policy; the Dirty Frag bugs no longer exist in the patched kernel, so the module block is no longer needed.