← Back to articles
Security· 2 min read

Fragnesia (CVE-2026-46300): a skb_try_coalesce bug hands out local root on the Linux kernel

Fragnesia is the third local-root flaw to land in the same corner of the Linux kernel in roughly two weeks, and it may be the nastiest of the bunch. William Bowling, from the V12 security team, found it, and AlmaLinux published the advisory and fixed kernels on 13 May 2026. A working proof-of-concept was already public when the bug went out, so this is not a theoretical problem.

Where the bug lives

The flaw sits in skb_try_coalesce(), a function in the core socket-buffer code (the sk_buff structures the kernel uses to handle every network packet). When the kernel tries to merge two buffers to save memory, that function moves the paged fragments from one buffer into the other. The trouble is that it fails to propagate the SKBFL_SHARED_FRAG marker during the transfer.

That marker is how the kernel remembers that a fragment is backed by external memory, such as page-cache pages that come straight from a file on disk. Lose the marker, and the kernel assumes those fragments belong to it and treats them as ordinary memory it can rewrite at will.

How it turns into root

The XFRM ESP-in-TCP receive path performs in-place AES-GCM decryption, meaning it decrypts directly over the same pages that hold the data. If those pages are page-cache pages from a read-only file, and the kernel has lost track of the fact that they are externally backed, the attacker gets a powerful primitive: XOR a chosen keystream over the contents of that file.

The obvious target is a setuid binary like /usr/bin/su. By tampering with its page-cache pages, an unprivileged process rewrites code that later runs as root. That is the jump to full root without any classic memory-corruption exploit. The primitive here is a controlled write over system files.

Who is affected

The bug is in the esp4, esp6 and rxrpc modules and the socket-buffer core code they share. According to AlmaLinux, every supported release (8, 9 and 10) was vulnerable. Given the nature of the affected code, any Linux kernel with those loadable modules sits in the same risk group, not just AlmaLinux. You can check the state of the supported branches in our AlmaLinux page.

Patch and mitigation

The right move is to update the kernel and reboot. The fixed versions AlmaLinux shipped are:

  • AlmaLinux 8: kernel-4.18.0-553.124.3.el8_10 or later
  • AlmaLinux 9: kernel-5.14.0-611.54.5.el9_7 or later
  • AlmaLinux 10: kernel-6.12.0-124.56.3.el10_1 or later

If you cannot reboot right away, the stopgap is to block the affected modules from loading. Create a file such as /etc/modprobe.d/fragnesia.conf with blacklist esp4, blacklist esp6 and blacklist rxrpc lines. Note that this breaks IPsec ESP if you rely on it. Treat it as temporary until the new kernel is installed and the box has rebooted.

If you want to see how kernel-level isolation and decryption flaws get exploited, we covered a related case in VMSCAPE (CVE-2025-40300).

Source

Related systems

Linux Kernel