Mitigating Fragnesia (CVE-2026-46300) on Rocky Linux 8, 9, 10, and LTS variants

cve cve-2026-46300 security kernel rocky linux lts mitigation troubleshooting

Arsalan Zaidi
Customer Support Engineering Lead

May 13, 2026

Introduction

Fragnesia, tracked as CVE-2026-46300, is an LPE vulnerability in the Linux kernel's xfrm ESP-in-TCP path. A local unprivileged user can exploit the flaw to write arbitrary bytes into the kernel page cache and gain root privileges without requiring a race condition. The vulnerability belongs to the same page-cache corruption class as Dirty Frag, CVE-2026-43284, but reaches the kernel through a distinct code path with a different underlying mechanism.

The researcher disclosed this vulnerability without coordinating with kernel maintainers or Linux distributions in advance. Upstream and downstream fixes are in progress concurrently as a result. A patch is under review on the netdev mailing list and hasn't landed in any kernel yet.

This article covers Rocky Linux 8, 9, and 10 systems, including CIQ LTS, FIPS, and RLC Pro variants. It describes what the vulnerability affects, how to apply the mitigation, and how to confirm the mitigation covers the system. CIQ Bridge for CentOS 7 is not affected

Problem

Fragnesia targets the xfrm ESP-in-TCP ULP. When an attacker splices file data into a TCP socket's receive queue and then transitions the socket to espintcp ULP mode, the kernel incorrectly treats those queued file pages as ESP ciphertext and begins decrypting them. The kernel XORs AES-GCM keystream bytes directly into the cached file pages. Because the attacker controls the IV nonce, they select a keystream byte that produces any desired output value at any offset, one byte per invocation. The on-disk file stays untouched. Only the page cache entry changes.

The exploit builds a 256-entry lookup table mapping keystream bytes to the nonces that produce them, then iterates over a payload, targeting each byte that needs changing. It overwrites the first 192 bytes of the /usr/bin/su page cache entry with a minimal position-independent ELF stub that calls setresuid/setresgid/execve /bin/sh. When any local user subsequently invokes su, the replacement binary executes and grants root access.

Unlike CVE-2026-43284, Fragnesia doesn't depend on a race condition. The write is deterministic once the attacker sets up the socket and SA, making the exploit reliable and fast to run.

Treat the following systems as affected unless they have the mitigation in place or are running a patched kernel:

Rocky Linux 8, 9, and 10 community releases
Rocky Linux 8 and 9 LTS variants
RLC Pro FIPS variants
RLC Pro variants based on Rocky Linux 8, 9, or 10, including RLC Pro Hardened

The attack requires local code execution and the ability to configure an xfrm SA with an ESP-in-TCP ULP. Treat any system with local shell users, shared app accounts, CI runners, or workloads that allow an attacker to run code as exposed until you apply the mitigation or install a patched kernel.

Status

No patched kernels are available as of 2026-05-13. The upstream fix is under review on the netdev mailing list. CIQ updates this article with a Patched kernels table once the fix lands in stable and testing completes.
The Dirty Frag mitigation also covers Fragnesia. Both vulnerabilities use the same kernel modules, esp4 and esp6, as the attack surface. If you already applied the Dirty Frag mitigation and /etc/modprobe.d/dirtyfrag.conf is present and active, the mitigation already covers Fragnesia. Verify this is still in effect using the steps in the Verification section below.
Recommended action for unmitigated systems: block esp4 and esp6 as described in the Mitigation section.
Open a support case if you need help assessing exposure, validating IPsec impact, or tracking patched kernel availability for your specific CIQ variant.

Patched kernels

No patched kernels are available as of 2026-05-13. CIQ updates this table as tested kernels become available for each variant.

Mitigation

Two mitigation options are available. If your hosts run kernel IPsec (strongSwan, libreswan, or similar), use the namespace sysctl option to avoid disrupting VPN or tunnel traffic. If they don't run IPsec, blocking the esp4 and esp6 modules is simpler and aligns with the existing Dirty Frag mitigation if you already have it in place.

Checking for prior exploitation

If the Fragnesia exploit has already run on the system, the attacker's modified su binary remains in the kernel page cache. Any local user can use su to gain root access without a password until you clear the page cache, regardless of whether you apply the module-blocking mitigation afterward.

To clear the cached modification without rebooting:

sudo sysctl vm.drop_caches=1

Before running this command, ensure no open su sessions exist on the system. Running su processes hold a reference to the binary's page cache pages, which prevents drop_caches from evicting them. Close all su sessions first, or reboot instead.

To check whether an attacker exploited the system, compare the SHA256 hash of /usr/bin/su before and after dropping caches:

sha256sum /usr/bin/su
sudo sysctl vm.drop_caches=1
sha256sum /usr/bin/su

If the hashes differ, the page cache version of su changed, indicating exploitation. After dropping caches, the on-disk binary takes effect again. If a reboot is acceptable, rebooting clears the entire page cache and is the simplest recovery path.

Disabling unprivileged network namespaces

The Fragnesia exploit requires unprivileged network namespace creation. Blocking that capability stops the exploit without unloading any kernel modules or interrupting IPsec traffic. This is the preferred mitigation on hosts running kernel IPsec.

Warning: Disabling unprivileged network namespace creation breaks rootless container runtimes including rootless Podman, rootless Docker, slirp4netns, and pasta. It also breaks sandboxed browsers such as Chromium and Firefox, and Flatpak applications. Validate the impact on your workload before applying fleet-wide.

If you already have /etc/sysctl.d/dirtyfrag.conf from the Dirty Frag advisory with user.max_net_namespaces=0, it covers Fragnesia as well. You don't need any additional configuration. Verify it's still active with sysctl user.max_net_namespaces.

To apply on a system that doesn't already have the Dirty Frag mitigation:

echo "user.max_net_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Verify:

sysctl user.max_net_namespaces

Output should be user.max_net_namespaces = 0.

To revert after installing a patched kernel:

sudo rm /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Disabling unprivileged user namespaces using user.max_user_namespaces=0 also blocks the exploit but has a wider blast radius. Use it only if the workload has no dependencies on user namespaces.

Block the kernel modules

Block the esp4 and esp6 modules to prevent Fragnesia from reaching the vulnerable code path. This is the same mitigation used for CVE-2026-43284, Dirty Frag. If you already applied the Dirty Frag mitigation and /etc/modprobe.d/dirtyfrag.conf is present and contains rules for esp4 and esp6, skip this step and proceed directly to Verification.

Warning: Blocking esp4 and esp6 disables kernel IPsec ESP. IPsec VPNs or tunnels that use the kernel IPsec stack, including common strongSwan and libreswan deployments, stop working. Validate the impact on your workload before applying this mitigation to production systems that use IPsec.

Step 1: install the modprobe override.

If you don't already have the Dirty Frag mitigation in place, create the override file. The recommended form includes rxrpc as well, which protects against CVE-2026-43500, the rxrpc variant of Dirty Frag, on Rocky 9 and 10:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf"

If rxrpc coverage isn't needed (Rocky 8-only environments, or sites that have already addressed CVE-2026-43500 separately), a minimal Fragnesia-specific override is also sufficient:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/fragnesia.conf"

Use dirtyfrag.conf as the filename when both vulnerabilities are a concern, since it keeps the mitigation state in one place.

Step 2: clear any resident copies of the modules.

The modprobe override blocks future load attempts but has no effect on modules already in memory. If esp4 or esp6 has active consumers (such as an active IPsec SA), rmmod fails and the running kernel remains exposed. Two paths to clear it.

Perform a reboot. This is the preferred path.

sudo reboot

After the reboot, the modprobe override blocks the modules from loading. Plan a maintenance window if the host runs production IPsec workloads.

Unloading without a reboot.

If a reboot isn't feasible, drop the active state holding the modules:

# Stop the IPsec daemon (libreswan example, adjust for strongSwan)
sudo systemctl stop ipsec

# Flush any remaining XFRM state and policies
sudo ip xfrm state flush
sudo ip xfrm policy flush

# Unload the modules
sudo rmmod esp4 esp6

Once the modules are out of memory, the modprobe override catches every subsequent load attempt. This path still interrupts IPsec service, so schedule a maintenance window.

Verification

Confirm the modules aren't active:

lsmod | grep -E '^(esp4|esp6)[[:space:]]'

No output means neither module is currently loaded.

Confirm the module-blocking file is present and has the correct content:

cat /etc/modprobe.d/dirtyfrag.conf

If you created a Fragnesia-specific file:

cat /etc/modprobe.d/fragnesia.conf

You should see install esp4 /bin/false and install esp6 /bin/false entries.

Confirm modprobe respects the override on future load attempts:

sudo modprobe -n -v esp4
sudo modprobe -n -v esp6

Each command should print install /bin/false. If either resolves to a .ko path, re-check the conf file is present and readable, and re-run the modprobe override command in Step 1.

If either module still appears in lsmod after applying the mitigation, the running kernel remains exposed. If you rebooted and the module still appears in lsmod, the override isn't catching the early-boot load path: confirm the conf file is present and readable, rebuild the initramfs to include the modprobe config, and reboot again. If you used the no-reboot path, a consumer is still holding the module. Re-run ip xfrm state and ip xfrm policy to confirm they're empty and ensure no other process has the module open before retrying rmmod.

Reverting the mitigation

Once you install a patched kernel for your variant, remove the module-block to restore IPsec ESP.

If you're using the shared Dirty Frag conf file at /etc/modprobe.d/dirtyfrag.conf, follow the revert procedure from the Dirty Frag KB article. Removing that file removes protection for both CVE-2026-43284 and CVE-2026-43500 at the same time, so confirm patched kernels are available for both vulnerabilities before reverting.