Dirty Frag Linux kernel local privilege escalation vulnerability mitigations

Two local privilege escalation (LPE) vulnerabilities affecting the Linux kernel have been publicly disclosed on May 7, 2026. One of the vulnerabilities has been assigned the ID: CVE-2026-43284. The other CVE ID is pending. Both are referred to as “Dirty Frag.” The affected components are Linux kernel modules. The first vulnerability impacts the modules that provide support for ESP (Encapsulating Security Protocol), one of the protocols used for IPsec (Internet Protocol Security). The second vulnerability impacts the modules that provide support for RxRPC, a protocol used for AFS (Andrew File System), a distributed file system. The vulnerabilities affect multiple Linux distributions, including all Ubuntu releases.

The vulnerabilities do not have CVSS scores assigned in the CVE List or NVD, but are assessed by Canonical to have a CVSS 3.1 score of 7.8, corresponding to a severity of HIGH.

This post describes mitigations that disable the affected modules and can be applied when Linux kernel packages which implement the proposed patch will be released.

Impact

Deployments without container workloads

On hosts that do not run container workloads, the vulnerability allows a local user to elevate privileges to the root user. The published exploit executes in this type of deployment.

Container deployments

In container deployments that may execute arbitrary third-party workloads, the vulnerability may additionally facilitate container escape scenarios, in addition to local privilege escalation on the host. A proof-of-concept exploit has not been published yet for container escape.

Mitigation regression risk

The mitigations disable the kernel modules that are used for IPsec ESP and RxRPC, respectively. The mitigations will affect functionality if these are in use by either:

• IPsec deployments. These are common with VPN implementations such as StrongSwan.
• AFS (Andrew File System) or another application of RxRPC.

As the vulnerabilities are independent, disabling only the esp4/esp6 modules or only the rxrpc modules would leave the remaining ones exploitable.

Affected releases

The vulnerability fix will be distributed through the Linux kernel image packages. A mitigation which disables the affected modules can be applied according to the instructions below. The mitigation will not be necessary once the kernel is updated.

How to check if you are impacted

All of the releases from the table above are impacted.

Manual mitigation

The mitigations block the affected kernel modules from loading. This requires three steps:

1. Prevent the modules from loading in the future.
2. Unload the modules.
3. Check whether step 2 was successful; if not, reboot the system.

Step 1 – block the modules:

Block the modules by creating a /etc/modprobe.d/dirty-frag.conf file:

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 being loaded during early boot:

sudo update-initramfs -u -k all

Step 2 – unload modules:

Unload the modules, in case they are already loaded:

sudo rmmod esp4 esp6 rxrpc 2>/dev/null 

Step 3 – confirm the modules aren’t loaded:

Check whether the modules are still loaded:

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

If the previous action indicates that the modules are not loaded, no further action is required. However, unloading the modules may not be possible if they are in use by applications. In these instances, a system reboot will enforce their blocking, but will affect applications:

sudo reboot

Disabling the mitigation

Once kernel updates are available and installed, the mitigation can be removed:

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