Two local privilege escalation (LPE) vulnerabilities affecting the Linux kernel have been publicly disclosed on May 7, 2026. The vulnerabilities have been assigned the IDs CVE-2026-43284 and CVE-2026-43500 and 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.

CVE-2026-43284 is assessed by the kernel.org CNA to have a CVSS 3.1 score of 8.8 (HIGH). CVE-2026-43500 is assessed by the NVD and CISA to have a CVSS 3.1 score of 7.8 (HIGH), aligned with the assessment by Canonical prior to the scores being assigned.

Linux kernel package updates are available that fix these vulnerabilities. This blog had been published on the day the vulnerability was publicly disclosed, describing mitigations that disable the affected components. The mitigations are no longer necessary if the Linux kernel updates are applied.

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

Update: Linux kernel package updates that fix these vulnerabilities are available and mitigations described here are no longer needed. We recommend that you install the Linux kernel update and only apply the mitigations if that is not possible.

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 is distributed through the Linux kernel image packages. A mitigation which disables the affected modules can be applied according to the instructions below, which have been published on the public disclosure date of the vulnerability. The mitigation is no longer necessary if the Linux kernel updates are applied.

How to check if you are impacted

On your system, run the following command to get the version of the currently running kernel and compare the listed version to the corresponding table above.

uname -r

The list of installed kernel packages can be obtained using the following command:

dpkg -l 'linux-image*' | grep ^ii

Security updates

We recommend you upgrade all packages:

sudo apt update && sudo apt upgrade

If this is not possible and the Linux kernel is installed via a meta package, its update can be targeted directly:

sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install --only-upgrade

Once the security updates for the Linux kernel are installed, a reboot is required:

sudo reboot

The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This service:  

• Applies new security updates every 24 hours automatically.
• If you have this enabled, the patches above will be automatically applied within 24 hours of being available, but a reboot is still required.

Manual mitigation

Update: Linux kernel security updates that fix the vulnerability are now available. The mitigations described in this section are no longer needed and should only be applied if the Linux kernel cannot be updated. If you have previously configured the mitigations, please follow the instructions in the ‘Disabling the mitigation’ section below.

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 installed, the mitigation can be removed:

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