Fragnesia (CVE-2026-46300): Patched kernels available in testing

Less than a week after Dirty Frag , researcher William Bowling of the V12 security team has disclosed a third Linux kernel local-root flaw in the same broad code area (IPsec ESP / rxrpc ) that they have named Fragnesia , tracked as CVE-2026-46300 . The proof-of-concept is published in V12’s pocs repository on GitHub and the upstream patch was posted to the netdev mailing list earlier today .

Fragnesia is a separate bug from Dirty Frag, but it lives in the same surface and chains through the same modules ( esp4 , esp6 , rxrpc ). The underlying flaw is in the core socket-buffer code: skb_try_coalesce() failed to propagate the SKBFL_SHARED_FRAG marker when transferring paged fragments between buffers, so the kernel could lose track of the fact that a fragment was externally backed (e.g. by page-cache pages spliced in from a file). The XFRM ESP-in-TCP receive path would then perform in-place AES-GCM decryption directly over those page-cache pages, allowing an unprivileged process to XOR a chosen keystream into read-only files such as /usr/bin/su and gain root.

Like Copy Fail and Dirty Frag before it, Fragnesia immediately yields root on all major distributions . Every supported AlmaLinux release is affected. The flaw is tracked as CVE-2026-46300, and the proof-of-concept is already public.

If you run AlmaLinux on a multi-tenant host, container build farm, CI runner, or any system where untrusted users can get a shell, this one matters, and with public exploit code in the wild, it matters today.

More information the vulnerability:

Security is a top priority at AlmaLinux, and the severity of this flaw, combined with how trivial it is to exploit, and the fact that this is now the third local-root in this code area in under two weeks, means we did not want to wait. Patches are not yet available from Red Hat , so our core team has built patched kernels using the upstream skbuff fix backported and adapted to each supported AlmaLinux branch. The decision to ship these ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo .

These kernels are available in the testing repository today . After the community has helped verify them, we will release them to the production repositories. This blog post will be updated when that happens.

It only takes a few steps to install and test the patched kernel from the testing repo.

Install the testing repo

Reboot to load the new kernel

Confirm you are running the patched kernel

The patched kernel versions are listed below. Use either of these commands:

We don’t recommend keeping the testing repo enabled after you’ve updated, unless you’ve done this on a truly non-production environment. If this is a production environment, you can disable the repo with this command:

If you encounter problems, please let us know as soon as you can, either in AlmaLinux chat or on bugs.almalinux.org .

AlmaLinux Kitten 10 is itself a development release and does not have a separate testing repository. A dedicated patched build for Kitten is being prepared and will ship directly to Kitten’s regular repository shortly after the stable AlmaLinux versions, so when it lands there is nothing extra to enable. Just update and reboot:

Confirm with uname -r against the Kitten version listed below once it has been posted.

All supported AlmaLinux releases (8, 9, 10) are affected through esp4 / esp6 , which are part of the standard kernel package on every release.

AlmaLinux 9 and 10 are additionally affected through rxrpc , but only on systems that have installed the kernel-modules-partner package. That package ships rxrpc.ko and lives in the AlmaLinux Devel repository, which is publicly available but kept outside the default release set. AlmaLinux 8 does not build the rxrpc module at all. If you don’t know what kernel-modules-partner is or whether it’s installed, you almost certainly don’t have it. rpm -q kernel-modules-partner will tell you.

Patched kernel versions:

The good news: because Fragnesia reaches root through the same esp4 / esp6 / rxrpc modules as Dirty Frag, the same mitigation from the Dirty Frag post blocks Fragnesia as well . If you already applied it, you are already protected against this one. There is nothing extra to do until you install the patched kernel.

If you have not applied it, you can neutralize the attack surface by blacklisting the affected modules. None of esp4 , esp6 , or rxrpc are loaded on a typical workload that does not use IPsec transport mode or AFS, so on most systems this is safe to apply immediately:

This writes a modprobe config that prevents the three modules from loading, and unloads them if they happen to be loaded already (the rmmod is best-effort and silent if the module isn’t present). The command is safe to run unchanged on all supported releases. To revert, remove /etc/modprobe.d/fragnesia.conf .

The Fragnesia exploit works by corrupting page-cache pages of sensitive files (such as /usr/bin/su ). If you suspect the system may have already been targeted before you applied the mitigation, drop the page cache so any tampered pages are evicted and the read comes fresh from disk:

This is safe to run on a live system (it only frees clean cache and dentry/inode entries) and pairs well with the blacklist above.

Do not rely on this if you actually use IPsec ESP or AFS/rxrpc. Those workloads will break. The proper fix is to install the patched kernel and reboot.

Thanks to William Bowling of the V12 security team for finding, writing up, and authoring the upstream skbuff patch for this vulnerability.

Thanks again to the AlmaLinux core team for turning around patched builds for every supported release on disclosure day, and to ALESCo for moving quickly to approve shipping ahead of upstream for the third time in under two weeks. And thank you in advance to everyone in the community who helps us test these kernels. That’s the part that gets them safely into production.