Mitigation Guide: Linux Kernel "Dirty Frag" (CVE-2026-43284 / CVE-2026-43500)

Internal procedure for identifying and mitigating the "Dirty Frag" local privilege escalation vulnerabilities across Ubuntu and RHEL-based distributions.

Linux Kernel "Dirty Frag" Mitigation Guide

Two local privilege escalation (LPE) vulnerabilities affecting the Linux kernel were publicly disclosed on May 7, 2026. They are collectively referred to as "Dirty Frag."

  • CVE-2026-43284 — impacts esp4/esp6 modules (IPsec ESP). CVSS 3.1: 8.8 (HIGH) per kernel.org CNA.
  • CVE-2026-43500 — impacts rxrpc module (AFS/RxRPC). CVSS 3.1: 7.8 (HIGH) per Canonical.
  • RHSB-2026-003 — Red Hat Security Bulletin covering both CVEs.
  • Ubuntu Dirty Frag — Ubuntu Security Bulletin covering both CVEs.

On hosts without container workloads, exploitation allows a local user to elevate privileges to root. In container deployments running arbitrary third-party workloads, the vulnerability may additionally facilitate container escape.

This guide covers mitigation (blocking the affected modules) to be applied until patched kernel packages are released. Perform the verification steps first to determine if a system requires action, then assess impact before applying the blocklist.

Warning: Blocklisting esp4/esp6 will break IPsec functionality. Blocklisting rxrpc will break AFS client connectivity. As the vulnerabilities are independent, disabling only one set of modules leaves the other exploitable. Evaluate the impact on your environment before applying.


Automated Mitigation Script

For most hosts the steps below can be run interactively via the CSS team's dirty-copy-mit.sh script. It auto-detects Ubuntu vs RHEL, performs the verification and impact checks described in this guide, and applies the appropriate vendor-recommended mitigation. The same script also covers Copy Fail (CVE-2026-31431). Reboots require an explicit typed confirmation.

Repository: https://git.doit.wisc.edu/CPKLECKER/dirtyfragmitigation

Download and run:

curl -fLO 'https://git.doit.wisc.edu/CPKLECKER/dirtyfragmitigation/-/raw/main/dirty-copy-mit.sh'
chmod +x dirty-copy-mit.sh
sudo ./dirty-copy-mit.sh

From the menu, select options 1, 2, or 3 for the Dirty Frag workflow. Option a reports the status of both Dirty Frag and Copy Fail at once.

The remainder of this document describes the manual procedure, which the script implements step-for-step. Use the manual steps when scripted execution is not available, when remediating non-standard environments, or for audit and review.


1. Ubuntu Systems

Step 1.1: Verify Vulnerability Status

Check if the affected modules are already blocked:

modprobe -n -v esp4 && modprobe -n -v esp6 && modprobe -n -v rxrpc
  • Already Mitigated: If all three return install /bin/false, no further action is required.
  • Vulnerable: If any output shows a path to a .ko file, proceed to Step 1.2.

Step 1.2: Check for Active IPsec or AFS Usage

Before applying the blocklist, determine whether the system relies on IPsec or AFS.

Check IPsec:

lsmod | grep -E 'esp4|esp6'

If the modules are loaded, verify whether IPsec is actively configured:

ip xfrm state
ip xfrm policy

If either returns entries, IPsec is in active use. Do not apply the esp4/esp6 blocklist without evaluating the "No Impact to IPsec Method" in the upstream advisory.

Check AFS:

lsmod | grep -E 'rxrpc|openafs'
mount | grep afs
pgrep -a afsd

If none of those return results, AFS is not in use and rxrpc is safe to blocklist.

Note: An empty /afs directory may exist as leftover from a previous installation. Confirm with mountpoint /afs — if it reports "not a mountpoint," AFS is not active.

Step 1.3: Check Reference for Target Version

Patched kernel packages for Ubuntu have not been released as of this writing. This section will be updated when patches are available.

Release Package Fixed Version
Resolute Raccoon (26.04 LTS) linux Affected
Questing Quokka (25.10) linux Affected
Noble Numbat (24.04 LTS) linux Affected
Jammy Jellyfish (22.04 LTS) linux Affected
Focal Fossa (20.04 LTS) linux Affected
Bionic Beaver (18.04 LTS) linux Affected
Xenial Xerus (16.04 LTS) linux Affected
Trusty Tahr (14.04 LTS) linux Affected

Step 1.4: Apply Mitigation

If no patched package is available, manually disable the affected modules:

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Regenerate the initramfs images to prevent the modules from loading during early boot:

sudo update-initramfs -u -k all

Attempt to unload the modules immediately (will silently fail if not loaded or in use):

sudo rmmod esp4 esp6 rxrpc 2>/dev/null

Step 1.5: Verify Mitigation

Confirm the blocklist is active:

modprobe -n -v esp4 && modprobe -n -v esp6 && modprobe -n -v rxrpc

All three should return install /bin/false.

Confirm the modules are not loaded in the running kernel:

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

If the modules are still loaded (they were in active use and rmmod could not unload them), a reboot is required to enforce the blocklist:

sudo reboot

Step 1.6: Apply Patch (When Available)

When the repository provides a fixed kernel version, update and reboot:

sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r) && sudo reboot

Step 1.7: Remove Mitigation (After Patching)

Once the patched kernel is installed and running, remove the blocklist and regenerate initramfs:

sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all

2. RHEL Variants (Rocky, Alma, RHEL 8/9/10)

Step 2.1: Verify Kernel Version

Check your current running kernel version:

uname -r

Compare your output against the Fixed Version list below:

Patched kernel versions have not been released as of this writing. This section will be updated when patches are available.

Distribution Fixed Kernel Version
RHEL 10 TBD
RHEL 9 TBD
RHEL 8 TBD

If your version is lower than the target (once published), proceed to Step 2.2.

Step 2.2: Verify Mitigation Status

Check if the module blocklist is already in place:

modprobe -n -v esp4 && modprobe -n -v esp6 && modprobe -n -v rxrpc
  • Already Mitigated: All three return install /bin/false.
  • Vulnerable: Any shows a .ko path. Proceed to Step 2.3.

Step 2.3: Check for Active IPsec or AFS Usage

Before applying the blocklist, determine whether the system relies on IPsec or AFS.

Check IPsec:

lsmod | grep -E 'esp4|esp6'
ip xfrm state
ip xfrm policy

If ip xfrm returns entries, IPsec is in active use. Do not apply the esp4/esp6 blocklist without evaluating the "No Impact to IPsec Method" in the upstream advisory.

Check AFS:

lsmod | grep -E 'rxrpc|openafs'
mount | grep afs
pgrep -a afsd

If none return results, rxrpc is safe to blocklist.

Step 2.4: Apply Emergency Mitigation

If a patched kernel is unavailable, apply the module blocklist:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf

Attempt to unload the modules immediately:

sudo rmmod esp4 esp6 rxrpc 2>/dev/null; true

Step 2.5: Verify Mitigation

Confirm the blocklist is active:

modprobe -n -v esp4 && modprobe -n -v esp6 && modprobe -n -v rxrpc

All three should return install /bin/false.

Confirm the modules are not loaded:

lsmod | grep -E 'esp4|esp6|rxrpc' && echo "Affected module(s) still loaded" || echo "No affected modules loaded"

If modules are still loaded, reboot:

sudo reboot

Step 2.6: Standard Patching (When Available)

When the repository provides the fixed kernel version, update and reboot:

sudo dnf update kernel -y && sudo reboot

Step 2.7: Remove Mitigation (After Patching)

Once the patched kernel is running, remove the blocklist:

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


Keywords:
How-To, Security, Linux, Kernel, CVE-2026-43284, CVE-2026-43500, RHSB-2026-003, Dirty Frag, Networking, Privilege Escalation, Mitigation, Internal IT 
Doc ID:
161229
Owned by:
Conor K. in CALS Information Technology
Created:
2026-05-11
Updated:
2026-05-11
Sites:
CALS Information Technology