Mitigating Dirty Frag (CVE-2026-43284) on Rocky Linux 8, 9, 10, and LTS Variants

cve security kernel rocky linux lts mitigation troubleshooting

Stephen Simpson
Customer Support Engineer

May 07, 2026

Introduction

Dirty Frag is a pair of local privilege escalation (LPE) vulnerabilities in the Linux kernel:

CVE-2026-43284 — the ESP variant, in the kernel IPsec data path
CVE-2026-43500 — the rxrpc variant, exploitable on Rocky 9 and 10

A local unprivileged user can use the vulnerable kernel paths to corrupt page cache contents and gain root privileges. The two CVEs share the Dirty Frag name and the same overall page-cache corruption technique, but reach the kernel through different code paths and require separate mitigations.

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 mitigations, 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
RLC Pro FIPS variants
RLC Pro variants based on Rocky Linux 8, 9, or 10 including RLC Pro Hardened

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

Patched kernels are available for all supported variants as of 2026-05-10. See the Patched Kernels table below.
Recommended action: install the patched kernel. Run sudo dnf update kernel* and reboot. See Installing the Update below for variant-specific instructions. If you cannot schedule a reboot immediately, apply one of the temporary mitigations in the Mitigation section to reduce exposure until the update can be applied. The mitigations are not required on systems already running a patched kernel.
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.
CIQ Bridge customers and CentOS 7.9 users are unaffected by the Dirty Frag exploit.
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

Variant	Patched Kernel Version	Released
RLC Pro LTS 8.6	`kernel-4.18.0-372.32.1+25.1.el8_6_ciq`	2026-05-08
RLC Pro LTS 8.10	`kernel-4.18.0-553.123.1+3.1.el8_10_ciq`	2026-05-08
RLC Pro LTS 9.2	`kernel-5.14.0-284.30.1+28.1.el9_2_ciq`	2026-05-10
RLC Pro LTS 9.4	`kernel-5.14.0-427.42.1+20.1.el9_4_ciq`	2026-05-10
RLC Pro LTS 9.6	`kernel-5.14.0-570.60.1+9.1.el9_6_ciq`	2026-05-08
RLC Pro FIPS 8.6	`kernel-4.18.0-553.123.1+3.1.el8_6.ciqfips`	2026-05-08
RLC Pro FIPS 8.10	`kernel-4.18.0-553.123.1+3.1.el8_10_ciq`	2026-05-08
RLC Pro 8	`kernel-4.18.0-553.123.1+3.1.el8_10_ciq`	2026-05-08
RLC Pro 9	`kernel-5.14.0-611.54.1+3.1.el9_7_ciq`	2026-05-10
CIQ SIG/Cloud Next 8	`kernel-4.18.0-553.123.1+3.1.el8_10_ciq`	2026-05-08
CIQ SIG/Cloud Next 9	`kernel-5.14.0-611.54.1+3.1.el9_7_ciq`	2026-05-10
CIQ SIG/Cloud Next 10	`kernel-6.12.0-124.55.1+2.1.el10_1_ciq`	2026-05-10
CIQ Linux Kernel LT 6.12	`kernel-clk6.12-6.12.87-1.1.el9_clk`	2026-05-12
Rocky Linux 8.10 (Community)	`kernel-4.18.0-553.123.1.el8_10.0.1`	2026-05-08
Rocky Linux 9.7 (Community)	`kernel-5.14.0-611.54.1.el9_7.0.1`	2026-05-09
Rocky Linux 10.1 (Community)	`kernel-6.12.0-124.55.1.el10_1.0.1`	2026-05-09

Confirm what is running on a given system with:

uname -r

If your system reports one of the patched versions above (or newer), the fix is in place and the mitigation can be reverted. See Resolution.

Installing the Update

RLC Pro LTS and FIPS Variants

For RLC Pro LTS and FIPS variants (including LTS 8.6, LTS 9.2, LTS 9.4, LTS 9.6, FIPS 8.6, and FIPS 8.10), the patched kernel is available directly from the long-term support repository. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

RLC Pro 8, RLC Pro 9, RLC Pro 10, CIQ SIG/Cloud Next, and RLC Pro LTS 8.10

For RLC Pro 8, RLC Pro 9, RLC Pro 10, CIQ SIG/Cloud Next variants, and RLC Pro LTS 8.10, the patched kernel is available in the Core Repo. Refresh your DNF metadata and then enable the appropriate depot channel for your variant if you do not have the core repository configured:

sudo dnf refresh

Then enable the channel that matches your product:

sudo depot enable lts-8.10    # RLC Pro LTS 8.10
sudo depot enable rlc-pro-8   # RLC Pro 8 / CIQ SIG Cloud Next 8
sudo depot enable rlc-pro-9   # RLC Pro 9 / CIQ SIG Cloud Next 9
sudo depot enable rlc-pro-10  # RLC Pro 10 / CIQ SIG Cloud Next 10 [VERIFY: confirm channel name]

Once the channel is enabled or reenabled, install the update:

sudo dnf update kernel*
sudo reboot

Community Edition (RESF)

For Rocky Linux 8.10, 9.7, and 10.1 community editions from RESF, the patched kernel is available from the standard BaseOS repository. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

Mitigation

Apply the steps in this section only if you cannot immediately reboot to apply the patched kernel. Once you have installed the patched kernel and rebooted, the mitigations are not required and can be removed. See Resolution below.

If the system may have already been exploited

If the Dirty Frag exploit has already been run on the system, the attacker's modified su binary remains in the kernel page cache. Any local user can use su to gain root access without a password, even after applying the module-blocking mitigation above.

To clear the cached modification without rebooting:

sudo sysctl vm.drop_caches=1

Important: Before running this command, ensure no open su sessions exist on the system. Running su processes hold a reference to the binary's page cache pages, preventing drop_caches from evicting them. Close all su sessions first, or reboot.

To verify whether the system was exploited, compare the SHA of /usr/bin/su before and after dropping caches, or whether the drop_caches is effective on a known-exploited system:

bash
cd ~/dirtyfrag && ./exp
sha256sum /usr/bin/su
sudo sysctl vm.drop_caches=1
sha256sum /usr/bin/su

If the hashes differ, the page cache version of su was modified (consistent with the exploitation). After dropping caches, the original on-disk binary is restored.

If a reboot is acceptable, rebooting also clears the page cache entirely.

Disable unprivileged network namespaces (preserves IPsec)

An alternative mitigation for CVE-2026-43284 (the ESP variant) is to disable unprivileged network namespace creation. The published exploit chain reaches the vulnerable ESP code path by setting up an unprivileged network namespace; removing that entry point blocks the exploit without unloading any kernel modules. Independent runtime testing confirmed the exploit fails with dirtyfrag: failed (rc=1) once the sysctl is applied.

⚠️ WARNING This mitigation only addresses CVE-2026-43284. The rxrpc variant (CVE-2026-43500) remains exploitable on Rocky 9 and 10 unless rxrpc is also blocked (see the next section). Disabling unprivileged network namespace creation breaks rootless container runtimes (rootless Podman, rootless Docker, slirp4netns / pasta), sandboxed browsers (Chromium, Firefox sandbox), and Flatpak applications, since they all create unprivileged net namespaces. Validate the impact on your workload before applying fleet-wide.

To apply:

echo "user.max_net_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Verify:

sysctl user.max_net_namespaces

The output should be user.max_net_namespaces = 0.

Disabling unprivileged user namespaces (user.max_user_namespaces=0) also blocks the exploit, since user namespaces are a prerequisite for unprivileged network namespaces. That is a wider control with a larger blast radius; use it only if your workload already does not depend on user namespaces.

To revert once a patched kernel is installed:

sudo rm /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

For complete coverage of both CVEs without disabling kernel IPsec, combine this sysctl with an rxrpc-only modprobe override:

echo "install rxrpc /bin/false" | sudo tee /etc/modprobe.d/dirtyfrag-rxrpc.conf
sudo rmmod rxrpc 2>/dev/null

This addresses CVE-2026-43500 on Rocky 9 and 10 while keeping esp4 and esp6 available for IPsec.

Block the kernel modules (covers both variants, breaks IPsec and AFS)

Dirty Frag can also be mitigated by blocking the vulnerable esp4, esp6, and rxrpc modules and removing them from the running kernel. This addresses both CVE-2026-43284 and CVE-2026-43500 in a single step.

⚠️ 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.

Resolution

After rebooting with the patched kernel, verify that the running kernel matches the patched version listed in the Patched Kernels table:

uname -r

If your system reports one of the patched versions above (or newer), the fix is in place.

If you applied the module-block mitigation, remove it now:

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

If you applied the rxrpc-only modprobe override (/etc/modprobe.d/dirtyfrag-rxrpc.conf), remove that as well:

sudo rm /etc/modprobe.d/dirtyfrag-rxrpc.conf
sudo modprobe rxrpc

If you applied the sysctl mitigation, remove it:

sudo rm /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Confirm the modules 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.
Network namespaces are a valid mitigation for CVE-2026-43284 only. Setting user.max_net_namespaces=0 blocks the ESP variant without breaking IPsec, but it does not address CVE-2026-43500 (the rxrpc variant) on Rocky 9 and 10, and it breaks rootless container runtimes, sandboxed browsers, and Flatpak. Pair it with an rxrpc-only module block to cover both CVEs while preserving IPsec, or use the full module-block mitigation to address both variants in a single step. Disabling unprivileged user namespaces (user.max_user_namespaces=0) also works but has wider blast radius.
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.