Dirty Frag Linux Vulnerability Explained: What You Need to Know

A new linux vulnerability called "Dirty Frag" is causing serious security problems. Understanding this will allow you to take protective measures for your systems before an attacker exploits it. The exploitation tool has already been used in attacks, therefore there is no reason to wait to patch or implement a workaround.

What is a Local Privilege Escalation Anyway?

If you are already familiar with what Local Privilege Escalation (LPE) means; please go directly to the next section. For all others: a local privilege escalation attack enables someone that currently has limited access to a system (i.e., a shared server login, a web shell, or a container) to increase their level of access to root/administrator level. To accomplish this they do NOT have to enter from the outside. They simply have to be logged into the machine somehow.

Dirty Frag has much greater potential for exploitation compared with many other LPE bugs. Dirty Frag exploits the kernel's network and memory fragments processing layers in sequence rather than relying on a race-condition (which can depend on timing and be unreliable) making this attack consistent and reliably reproducible thus allowing an attacker to easily exploit this vulnerability once they have gained their first foothold into the target environment.

What Exactly is Dirty Frag?

The Dirty Frag bug is comprised of two different vulnerabilities in the Linux kernel that affect its networking component as well as its memory-fragment handling component. The first vulnerability is CVE-2026-43284 which affects esp4 and esp6; these are responsible for handling ESP (encapsulated security payload) which is one of the primary protocols within the IPsec framework. The second vulnerability is CVE-2026-43500 which affects rxrpc the protocol utilized by the AFS distributed file system.

An attacker who already has a foothold through SSH access, a web shell, a container escape, or even just a low-privileged account can use this chain to get full root on the host. Linux kernel vulnerabilities like this have become a consistent pattern in recent years, and Dirty Frag follows a worrying trend of exploits requiring no kernel race condition.

Am I Affected? Check Your Kernel Version

Run this one-liner on your server to check your current kernel:

uname -r

All kernels across every listed distro release are currently considered affected until a patched kernel package is installed. You can also check if the vulnerable modules are loaded right now. Note that some distros compile these under variant names like xfrm4_tunnel or xfrm6_tunnel, so cast a wider grep:

lsmod | grep -E 'esp|xfrm|rxrpc'

If that command returns any output containing esp4, esp6, or rxrpc, those modules are loaded and your system is exploitable until you apply the mitigation or a kernel update. Note the exact names shown, you will need them in the steps below.

Step-by-Step Mitigation by Distro

The temporary mitigation works by blocking the three kernel modules from loading. This is safe to apply now even before a kernel patch lands for your distro. The steps differ slightly between distro families, so follow the correct section below.

Ubuntu (All LTS and Current Releases)

Ubuntu 26.04 LTS and all releases back to 14.04 are confirmed affected.

Step 0: Confirm exact module names on your kernel

Distros sometimes compile esp4/esp6 under different names (xfrm4_tunnel, xfrm6_tunnel, etc.). Verify what your kernel is actually using before writing the conf file:

lsmod | grep -E 'esp|xfrm|rxrpc'

Use the exact names you see in the output in all commands below.

Step 1: Block and blacklist the modules

The install ... /bin/false line prevents loading via modprobe. The blacklist line stops the kernel from auto-loading the module via a device alias, for example when a specific packet type arrives on the network. Both lines are needed for complete coverage:

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

Step 2: Rebuild initramfs (deep hardening step)

This ensures the modules are not available even during the early boot sequence before the root filesystem is mounted. For most systems esp4, esp6, and rxrpc are loaded after boot, so this step is optional if you are in a hurry. It is still recommended as a belt-and-suspenders measure:

sudo update-initramfs -u -k all

Step 3: Unload modules if currently loaded

Use modprobe -r instead of rmmod. It handles the module dependency tree and unloads in the correct order, which prevents the "module is in use" failure you get with the bare rmmod command:

sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

Step 4: Verify they are gone

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Still loaded - reboot needed" || echo "Modules removed successfully"

Rocky Linux, AlmaLinux, and CentOS Stream

The mitigation process on RHEL-based systems including Rocky Linux follows a slightly different path because the initramfs tool differs.

Step 0: Confirm exact module names on your kernel

Some RHEL-family kernels use different compiled names for the ESP modules. Check before writing the conf file:

lsmod | grep -E 'esp|xfrm|rxrpc'

Step 1: Block and blacklist the modules

Include both install (blocks modprobe) and blacklist (blocks alias-based auto-loading) directives in the same file:

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

Step 2: Rebuild initramfs with dracut (deep hardening step)

For most systems these modules load after boot, so this is optional if you need speed. Still recommended for full coverage:

sudo dracut -f --regenerate-all

Step 3: Unload currently loaded modules

Use modprobe -r so it handles the dependency chain correctly:

sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null

Step 4: Verify

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Still loaded - reboot needed" || echo "Modules removed successfully"

Ubuntu vs Rocky Linux: Mitigation Differences at a Glance

Container and Cloud Environments

If you run Docker, Podman, or OpenShift workloads, the risk picture is more nuanced than a simple "higher risk" statement. Here is how it breaks down:

On a standard, well-hardened Docker container with no elevated capabilities, Dirty Frag escalates the attacker to root inside the container's network namespace. That is bad, but they are still isolated inside that jail. They do not automatically land on the host.

The real danger is with privileged containers (--privileged flag) or containers that have CAP_SYS_ADMIN, CAP_NET_ADMIN, or that share the host network namespace (--net=host). In those environments, escalating to root inside the container can translate directly to root on the underlying host. This is the actual container escape scenario and it applies to a large number of real-world workloads including many CI/CD runners and service mesh sidecars.

Apply the kernel module mitigation on the host in all cases. Also audit your running containers for --privileged and --net=host flags:

docker ps -q | xargs docker inspect --format '{{.Name}} Privileged={{.HostConfig.Privileged}} NetworkMode={{.HostConfig.NetworkMode}}'

Does SELinux or AppArmor Help?

Both SELinux (default on RHEL/Rocky/AlmaLinux) and AppArmor (default on Ubuntu) add access control layers that can limit what an exploit can do after escalation. However, neither fully prevents the Dirty Frag escalation itself. If a user can load or interact with the vulnerable modules, the LPE can still run. The kernel module block described above is the correct mitigation, not relying on MAC frameworks alone.

That said, keep SELinux in enforcing mode and AppArmor enabled on all systems. They add useful defense-in-depth and reduce the blast radius if any other exploit gets through alongside this one. The upcoming Linux 7.0 kernel is expected to include hardening improvements that may reduce the attack surface for this class of vulnerability.

Troubleshooting: What if the Mitigation Breaks Things?

IPsec / VPN stopped working after I blocked esp4 and esp6

This is expected if you use an IPsec-based VPN like StrongSwan or Libreswan. The esp4 and esp6 modules handle ESP traffic. Disabling them will break any tunnel using IPsec. You have two choices: accept the downtime and wait for a patched kernel, or evaluate whether your VPN can be temporarily switched to a non-IPsec protocol like WireGuard while you wait.

modprobe -r says the module is in use and won't unload

This happens when an active process is holding the module open. The /etc/modprobe.d/dirty-frag.conf file (with both install and blacklist directives) plus the initramfs rebuild will prevent the modules from loading on next boot. You can safely reboot to enforce the block immediately:

sudo reboot

How do I remove the mitigation after patching?

Once your distro ships a patched kernel and you have installed the update, remove the block file:

sudo rm /etc/modprobe.d/dirty-frag.conf

Then rebuild initramfs (Ubuntu: sudo update-initramfs -u -k all / Rocky: sudo dracut -f --regenerate-all) and reboot. Confirm the patched kernel is running with uname -r.