Dirty Frag Linux kernel local privilege escalation vulnerability mitigations
Luci Stanescu
on 8 May 2026
Tags: Security , Vulnerabilities
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.
| Release | Package Name | Fixed Version |
| Trusty Tahr (14.04 LTS) | linux | Not affected |
| Xenial Xerus (16.04 LTS) | linux | Not affected |
| Bionic Beaver (18.04 LTS) | linux | Linux 4.15: 4.15.0-251.263 Linux 5.4 (HWE): 5.4.0-231.251~18.04.1 |
| Focal Fossa (20.04 LTS) | linux | Linux 5.4: 5.4.0-231.251 Linux 5.15 (HWE): 5.15.0-181.191~20.04.1 |
| Jammy Jellyfish (22.04 LTS) | linux | Linux 5.15: 5.15.0-181.191 Linux 6.8 (HWE): 6.8.0-124.124~22.04.1 |
| Noble Numbat (24.04 LTS) | linux | Linux 6.8: 6.8.0-124.124 Linux 6.17 (HWE): 6.17.0-35.35~24.04.1 |
| Questing Quokka (25.10) | linux | 6.17.0-35.35 |
| Resolute Raccoon (26.04 LTS) | linux | 7.0.0-22.22 |
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:
- Prevent the modules from loading in the future.
- Unload the modules.
- 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
Talk to us today
Interested in running Ubuntu in your organisation?
Newsletter signup
Related posts
PinTheft Linux kernel vulnerability mitigation
A local privilege escalation (LPE) security vulnerability in the Linux kernel, codename “PinTheft,” was publicly disclosed on May 19, 2026. The vulnerability...
CVE-2026-46333 (ssh-keysign-pwn) Linux kernel vulnerability mitigations
An information disclosure security vulnerability in the Linux kernel was publicly disclosed on May 15th, 2026. The vulnerability was reported by Qualys and...
Finding the blind spot: How Canonical hunts logic flaws with AI
AI is accelerating and improving how security engineers find and fix vulnerabilities. A new tool developed and used at Canonical, called Redhound, has already...