
Update: Refreshed test builds available
2026-05-14: The patched kernels in almalinux-testing have been rebuilt to pick up additional upstream patches for Fragnesia that landed on the netdev list after our initial backport (see the two follow-up references below). If you already installed the earlier test build, please update and reboot again:
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot
The new NVRs are kernel-4.18.0-553.124.3.el8_10 (AL8), kernel-5.14.0-611.54.5.el9_7 (AL9), and kernel-6.12.0-124.56.3.el10_1 (AL10). They supersede the .124.2.el8_10 / .54.4.el9_7 / .56.2.el10_1 test builds. The matching AlmaLinux Kitten 10 build, kernel-6.12.0-227.el10, is still building; we will publish the update to Kitten as soon as that build finishes. Production rollout for AL8/9/10 will follow once the community has finished verifying.
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 about the vulnerability:
- NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-46300
- Red Hat security advisory: https://access.redhat.com/security/cve/CVE-2026-46300
- Proof-of-concept and write-up: https://github.com/v12-security/pocs/tree/main/fragnesia
- Upstream patch on netdev: https://lists.openwall.net/netdev/2026/05/13/79
- Patch subject:
[PATCH net] net: skbuff: preserve shared-frag marker during coalescing - Follow-up upstream patch: https://lore.kernel.org/all/agVpIsaSherjHTYg@sultan-box/
- Follow-up upstream patch: https://lore.kernel.org/all/agW4vC0r8QOUKtRT@v4bel/
Patching ahead of our upstream
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.
Help us test
It only takes a few steps to install and test the patched kernel from the testing repo.
Install the testing repo
sudo dnf install -y almalinux-release-testing
Update the kernel
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
Reboot to load the new kernel
sudo reboot
Confirm you are running the patched kernel
The patched kernel versions are listed below. Use either of these commands:
uname -r
rpm -q kernel
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:
sudo dnf config-manager --disable almalinux-testing
If you encounter problems, please let us know as soon as you can, either in AlmaLinux chat or on bugs.almalinux.org.
A note for AlmaLinux Kitten 10 users
AlmaLinux Kitten 10 is itself a development release and does not have a separate testing repository. The dedicated patched build for Kitten (kernel-6.12.0-227.el10) is still building and has not yet been published to Kitten’s regular repository. We will push the update out as soon as the build completes; once it lands there is nothing extra to enable, just update and reboot:
sudo dnf update 'kernel*'
sudo reboot
Confirm with uname -r against the Kitten version listed below once it has shipped.
Affected versions and patched kernels
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:
- AlmaLinux 8 is patched in
kernel-4.18.0-553.124.3.el8_10and above - AlmaLinux 9 is patched in
kernel-5.14.0-611.54.5.el9_7and above - AlmaLinux 10 is patched in
kernel-6.12.0-124.56.3.el10_1and above - AlmaLinux Kitten 10 will be patched in
kernel-6.12.0-227.el10(build still in progress; this section will be updated when it ships)
Temporary mitigation if you cannot reboot yet
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:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
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 next read comes fresh from disk:
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
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
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.
Stay informed
Remaining aware of these vulnerabilities and acting quickly can keep your system and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to Announce and Security mailing lists to stay informed and updated. We will update this post when the patched kernels move from testing to production.
Changelog
2026-05-14: Refreshed test builds released to
almalinux-testingwith additional upstream patches for Fragnesia. The new NVRs (kernel-4.18.0-553.124.3.el8_10for AL8,kernel-5.14.0-611.54.5.el9_7for AL9,kernel-6.12.0-124.56.3.el10_1for AL10) supersede the initial test builds (.124.2.el8_10,.54.4.el9_7,.56.2.el10_1). Added two follow-up upstream patches to the references list and an “Update” notice at the top of the post.2026-05-14: Confirmed the AlmaLinux Kitten 10 patched NVR will be
kernel-6.12.0-227.el10. The build is still in progress at the time of this update; the post will be updated again, and the package published to the Kitten repository, as soon as the build completes.2026-05-13: Initial post published; patched kernels available in
almalinux-testingfor AlmaLinux 8, 9, and 10. CVE-2026-46300 assigned and linked alongside the NVD and Red Hat security advisory entries.

