Fragnesia Linux kernel local privilege escalation vulnerability mitigations

A local privilege escalation (LPE) vulnerability affecting the Linux kernel has been publicly disclosed on May 13, 2026. The vulnerability does not have a CVE ID published, but is referred to as “Fragnesia.”  The vulnerability affects multiple Linux distributions, including all Ubuntu releases. The affected components are the Linux kernel modules that provide support for ESP (Encapsulating Security Protocol), one of the protocols used for IPsec (Internet Protocol Security). These are the same Linux kernel modules that were affected by one of the Dirty Frag vulnerabilities. As such, the mitigations described in the Dirty Frag vulnerability update provide protection against Fragnesia as well, since they disable the impacted Linux kernel modules.

The vulnerability does not have CVSS scores assigned in the CVE List or NVD, but Canonical’s assessment indicates a CVSS 3.1 score of 7.8, corresponding to a severity of HIGH.

This post describes mitigations that disable the affected modules. These mitigations can be applied until 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 mitigation disables the kernel modules that are used for IPsec ESP. Enabling the mitigation will affect functionality if the modules are in use by IPsec deployments. These are common with VPN implementations such as StrongSwan.

Affected releases

Once available, the vulnerability fix will be distributed through the Linux kernel image packages. In the interim, 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.

Please note that if you have previously applied the mitigations described for Dirty Frag, your system is not affected by Fragnesia.

ReleasePackage NameFixed Version
Trusty Tahr (14.04 LTS)linuxAffected
Xenial Xerus (16.04 LTS)linuxAffected
Bionic Beaver (18.04 LTS)linuxAffected
Focal Fossa (20.04 LTS)linuxAffected
Jammy Jellyfish (22.04 LTS)linuxAffected
Noble Numbat (24.04 LTS)linuxAffected
Questing Quokka (25.10)linuxAffected
Resolute Raccoon (26.04 LTS)linuxAffected

How to check if you are impacted

All of the releases from the table above are impacted, unless the Dirty Frag mitigations have been previously applied.

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.

The same modules are blocked by the Dirty Frag mitigations. Applying both mitigations does not cause any issues, but is unnecessary. However, we recommend that you maintain the mitigations until Linux kernel security updates that address both vulnerabilities are available and installed.

Step 1 – block the modules:

Block the modules by creating a /etc/modprobe.d/fragnesia.conf file:

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/fragnesia.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/fragnesia.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 2>/dev/null 

Step 3 – confirm the modules aren’t loaded:

Check whether the modules are still loaded:

grep -qE '^(esp4|esp6) ' /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/fragnesia.conf
sudo update-initramfs -u -k all

Please note that in order to restore IPsec availability, ESP modules must be permitted to be loaded. This means that the mitigations for Fragnesia described here as well as the mitigations for Dirty Frag will need to be removed to restore IPsec availability.

Talk to us today

Interested in running Ubuntu in your organisation?

Newsletter signup

Get the latest Ubuntu news and updates in your inbox.

By submitting this form, I confirm that I have read and agree to Canonical's Privacy Policy.

Related posts

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. The vulnerabilities have been...

Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability

A local privilege escalation (LPE) vulnerability affecting the Linux kernel has been publicly disclosed on April 29, 2026. The vulnerability has been assigned...

AppArmor vulnerability fixes available

Qualys discovered several vulnerabilities in the AppArmor code of the Linux kernel. These are being referred to as CrackArmor, while CVE IDs are in the...