Another local privilege escalation vulnerability has been revealed in the Linux kernel, named Fragnesia and identified as CVE-2026-46300. The issue falls under the same category of attacks on page cache as the recently discussed Copy Fail and Dirty Frag, but it is not a rehash of an old error: it concerns a distinct defect in the code of XFRM ESP-in-TCP.
The vulnerability was discovered by researcher William Bowling from the team of V12 Security. According to the published description, Fragnesia allows an unprivileged local user to modify the contents of read-only files in the page cache memory, and thus execute code with root privileges. Unlike many older LPE exploits, the attack does not require a race condition and is described by researchers as deterministic.
Technically, the issue relates to the fact that when merging network buffers, the kernel could lose the indication that a fragment of data is "shared" and associated with an external page of memory, including the page cache. The proposed patch describes this as an error in skb_try_coalesce(): when moving paged fragments from one sk_buff to another, the SKBFL_SHARED_FRAG flag was not preserved. As a result, later ESP code could mistakenly consider the buffer safe for modification.
The practical effect is that data previously placed in the TCP queue from a file, after switching the socket to ESP-in-TCP mode, could be processed by the kernel as ESP-encrypted text. During the AES-GCM decryption, the bytes were altered directly in the page cache page associated with the file. This does not change the file on the disk but alters its representation in memory until the page is evicted from the cache.
In the published attack demonstration, the target used was /usr/bin/su: the exploit modified the initial bytes of the binary file in the page cache and then executed the modified in-memory copy, gaining a shell with root privileges. The original file on disk remained unchanged, making the problem particularly troublesome for diagnosis: traces of exploitation may disappear after clearing the page cache or rebooting.
Fragnesia appeared less than a week after Dirty Frag. V12 emphasizes that this is a separate bug with the same attack surface — ESP/XFRM — and not a renaming of an already fixed vulnerability. Phoronix also notes that at the time of publication, a proof-of-concept was available, and the fix was a small patch to net/core/skbuff.c, which had not yet made it to the main branches of the kernel.
Canonical assigned CVE-2026-46300 high priority for Ubuntu, citing the reason as 'trivial local privilege escalation'. The Ubuntu Security page for the affected kernels indicated a status of 'Needs evaluation' as of the May 13 update, and it was noted separately that the issue is also present in the kernel's ESP module and can be temporarily mitigated in the same way as Dirty Frag.
Debian Security Tracker marked the kernels in the bullseye, bookworm, trixie, forky, and sid branches as vulnerable at the time of review; for the linux package in unstable, a fixed version had not yet been specified.
The temporary protective measure remains the same as for Dirty Frag: disable the loading of modules esp4, esp6, and rxrpc if they are not needed by the system. This may disrupt the operation of IPsec tunnels on nodes where kernel ESP, strongSwan, Libreswan, or similar configurations are used, so such a measure should only be implemented on VPN gateways after assessing the consequences.
An example of a temporary mitigation for administrators:
sudo sh -c "printf 'install esp4 /bin/falsetninstall esp6 /bin/falsetninstall rxrpc /bin/falsetn' > /etc/modprobe.d/dirtyfrag.conf" sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true
If there is suspicion that the system may have already been compromised, simply blocking the modules is not enough: since the public demonstration modifies the executable file directly in the page cache, administrators recommend clearing the page cache or rebooting the system after implementing protective measures. CloudLinux directly states that after exploitation, /usr/bin/su may remain modified in memory until the corresponding pages are evicted.
To remove the temporary rule after installing the patched kernel, you can delete the created file:
sudo rm /etc/modprobe.d/dirtyfrag.conf
The main recommendation remains standard: install the patched kernel from your distribution and reboot the system. Before the update, the greatest risk is posed by multi-user servers, CI runners, shared hosting, container build farms, and any machines where unprivileged or partially trusted users can execute local code.
Source: linux.org.ru
