Re: Linux kernel LPE ("fragnesia", copyfail 3.0)

[Greg KH <greg () kroah com>]

On Wed, May 13, 2026 at 11:59:37AM +0100, Sam James wrote:
> v12-security have disclosed "Fragnesia" [0]. Quoting their disclosure:
> > Fragnesia is a universal Linux local privilege escalation exploit,
> > discovered by William Bowling with the V12 team. Fragnesia is a member
> > of the Dirty Frag vulnerability class. This is a separate bug in the
> > ESP/XFRM from dirtyfrag which has received its own patch. However, it
> > is in the same surface and the mitigation is the same as for dirtyfrag.
> >
> > It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to
> > achieve arbitrary byte writes into the kernel page cache of read-only
> > files, without requiring any race condition.
>
> > The technique extends the page-cache write bug class that includes
> > Dirty Pipe: when a TCP socket transitions to espintcp ULP mode after
> > data has already been spliced from a file into the receive queue, the
> > kernel processes the queued file pages as ESP ciphertext. The AES-GCM
> > keystream byte at counter block position 2, byte 0 is XORed directly
> > into the cached file page. By selecting the IV nonce to produce a
> > desired keystream byte, any target byte in the file can be set to any
> > value — one byte per trigger invocation.
> >
> > The exploit builds a 256-entry lookup table mapping each possible
> > keystream byte to its corresponding nonce, then iterates over a
> > payload, firing the splice/ULP race for each byte that needs changing.
> > It writes a small position-independent ELF stub
> > (setresuid/setresgid/execve /bin/sh) over the first 192 bytes of
> > /usr/bin/su in the page cache, then calls execve("/usr/bin/su") to
> > obtain a root shell. The page cache modification is not backed to
> > disk; the on-disk binary is untouched.
>
> page cache part being copyfail again [0], but the actual bug is more
> like dirtyfrag [2]. They've also provided a PoC [3] (attached).
>
> There's a patch on netdev [4], not yet in that tree or in Linus's tree,
> therefore not in any stable kernels either.

For those that like to track these by CVE ids, CVE-2026-46300 has been
assigned for this issue.

hope this helps,

greg k-h