Contact us
Articles › Rocky Linux

Mitigating Dirty Frag on Rocky Linux 8, 9, 10, and LTS Variants

securitykernelrocky linuxltsmitigationtroubleshooting

Stephen Simpson
Customer Support Engineer

May 07, 2026

Introduction

Dirty Frag is a local privilege escalation (LPE) vulnerability in the Linux kernel. A local unprivileged user can use the vulnerable kernel paths to corrupt page cache contents and gain root privileges.

This article focuses on Rocky Linux 8, 9, and 10 systems, including CIQ LTS, FIPS, and RLC Pro variants built on those releases. It covers what is affected, how to apply the temporary mitigation, and which kernels are patched.

Problem

Dirty Frag affects systems where the vulnerable ESP or RxRPC kernel paths can be loaded or are already active. For the Rocky Linux family, the ESP path is the primary concern.

Treat the following systems as affected unless they are running a patched kernel listed in the Patched Kernels section or have the mitigation in place:

  • Rocky Linux 8, 9, and 10 community releases
  • Rocky Linux 8 and 9 LTS variants
  • Rocky Linux FIPS Compliant variants
  • RLC Pro variants based on Rocky Linux 8, 9, or 10 including RLC-H

Dirty Frag requires local code execution. It is not currently documented as a remote unauthenticated vulnerability by itself. However, any system with local shell users, shared application accounts, CI runners, or workloads that allow an attacker to run code should be treated as exposed until patched or mitigated.

Status

  • No patched kernels are available for Dirty Frag as of 2026-05-07. See the Patched Kernels table below.
  • Recommended action: apply the module-level mitigation published by the researcher immediately unless the system depends on kernel IPsec ESP or AFS, then either reboot or tear down the active IPsec / AFS state so the vulnerable modules can be unloaded.
  • The modprobe override blocks future loads only. CIQ lab testing confirmed that if esp4, esp6, or rxrpc is already resident in the running kernel with active consumers (an IPsec SA, AFS mount, etc.), rmmod fails because the kernel xfrm subsystem holds a refcount on the module for the lifetime of every active SA. The system stays exposed until that module is out of memory. See the Mitigation section for the two paths to clear it.
  • Open a support case if you need help validating exposure, assessing IPsec or AFS impact, or tracking patched kernel availability for a specific CIQ variant.

Patched Kernels

None available as of 2026-05-07.

Mitigation

Dirty Frag can be mitigated by blocking the vulnerable esp4, esp6, and rxrpc modules and removing them from the running kernel.

⚠️ WARNING Blocking esp4 and esp6 disables kernel IPsec ESP. IPsec VPNs or tunnels using the kernel IPsec stack, including common strongSwan and libreswan deployments, may stop working. Blocking rxrpc affects AFS clients. Validate the impact before applying this mitigation to production systems that use IPsec or AFS.

Step 1: install the modprobe override.

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

This file prevents future load attempts, including the kernel-driven auto-load that request_module("xfrm-type-2-50") triggers when a fresh ESP packet needs a transform. modprobe resolves the alias to the canonical module name, sees the install rule, and runs /bin/false instead of loading the module.

Step 2: clear any resident copies of the modules.

The override does nothing to modules already in memory. If esp4, esp6, or rxrpc is loaded with active consumers, rmmod will fail and the running kernel stays exposed. CIQ lab testing on a host with an active IPsec tunnel confirmed rmmod esp4 returns Module is in use, the module remains resident, and IPsec keeps working until the consumers are torn down. Two paths to clear it:

Option A (recommended): reboot.

sudo reboot

The simplest path. After the reboot, the modprobe override blocks the modules from loading and any consumer that tries to use them fails closed. Plan a maintenance window if the host runs production IPsec or AFS workloads.

Option B: tear down the consumers, then unload.

If a reboot is not feasible, drop the active state holding the modules:

# Stop the IPsec daemon (libreswan example, adjust for strongSwan)
sudo systemctl stop ipsec

# Flush any remaining XFRM state and policies
sudo ip xfrm state flush
sudo ip xfrm policy flush

# Unmount AFS volumes if rxrpc is in use, then unload all three
sudo rmmod esp4 esp6 rxrpc

Once the modules are out of memory, the modprobe override catches every subsequent load attempt, including the auto-load that ipsec start or a new SA install would otherwise trigger. This path also interrupts IPsec and AFS service, so it still requires a maintenance window.

Verification

Confirm that the modules are not active:

lsmod | grep -E '^(esp4|esp6|rxrpc)[[:space:]]'

No output means none of the blocked modules are currently loaded.

Then confirm the module-blocking file is present:

cat /etc/modprobe.d/dirtyfrag.conf

You should see one install ... /bin/false line for each module: esp4, esp6, and rxrpc.

Finally, confirm the override is actually being honored on a future load attempt:

sudo modprobe -n -v esp4
sudo modprobe -n -v esp6
sudo modprobe -n -v rxrpc

Each command should print install /bin/false. If any resolve to a .ko path, re-check /etc/modprobe.d/dirtyfrag.conf, confirm it is present and readable, and verify that modprobe is reading the config.

If any of the modules still appear in lsmod after applying the mitigation, the running kernel is still exposed. If you took Option A and rebooted, the override is not catching the early-boot load path: re-check /etc/modprobe.d/dirtyfrag.conf is present and readable, rebuild the initramfs so the modprobe config is included there, and reboot again. If you took Option B, a consumer is still holding the module; re-run ip xfrm state and ip xfrm policy to confirm they are empty, check for AFS mounts (mount | grep afs), and ensure no other process has the module open before retrying rmmod.

Reverting the Mitigation

Once a patched kernel is installed for your variant, remove the module-block so IPsec ESP and rxrpc come back online:

sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo modprobe esp4
sudo modprobe esp6
sudo modprobe rxrpc

Confirm they loaded:

lsmod | grep -E '^(esp4|esp6|rxrpc)[[:space:]]'

Reboot if the modules need to come up cleanly via initramfs. This is uncommon for esp4, esp6, or rxrpc; if you applied the mitigation on a STIG-hardened image or rebuilt the initramfs while the override was in place, a reboot ensures the running kernel matches the on-disk module state.

Notes

Before applying the mitigation fleet-wide, consider the following:

  • IPsec and VPN: esp4 and esp6 provide ESP support for kernel-managed IPsec. Removing them will break IPsec tunnels that depend on those modules.
  • AFS clients: rxrpc is required by the AFS kernel client. If the system does not use AFS, blocking rxrpc usually has no practical impact.
  • User namespaces are not a substitute for this mitigation. The public exploit chain reaches the vulnerable code paths through unprivileged user namespaces, so a system that has disabled unprivileged user namespace creation will block the published proof of concept. That is not the same as being patched. Apply the module-block mitigation regardless of user namespace settings; it is the direct control over the vulnerable code, and any future variant of the exploit may use a different entry point.
  • Public exploit availability: a working exploit exists. Treat affected systems with local users or untrusted workloads as exploitable until the mitigation is applied or a patched kernel is installed.

Related Articles