public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
* Unidentified Fragnesia Variant with Public PoC
@ 2026-05-28 15:12 Wade Sparks
  2026-05-28 16:16 ` Andrew Lunn
  2026-05-29  6:37 ` Jiayuan Chen
  0 siblings, 2 replies; 4+ messages in thread
From: Wade Sparks @ 2026-05-28 15:12 UTC (permalink / raw)
  To: netdev; +Cc: security, Disclosures


[-- Attachment #1.1: Type: text/plain, Size: 1230 bytes --]

Hello netdev team,
(cc: security@kernel•org)

The VulnCheck Research team recently discovered and successfully reproduced
a *public* proof of concept
<https://github.com/v12-security/pocs/tree/main/fragnesia-5db89c99566fc> (PoC)
published by V12 Security that targets an unidentified variant of
CVE-2026-46300, referred to as Fragnesia.

The original Fragnesia patch only addressed the coalesce path, leaving the
segmentation path independently exploitable. We confirmed the PoC works on
the latest Ubuntu kernel release <https://ubuntu.com/about/release-cycle>
as of 2026-05-27 (we are in the process of re-testing against v7.0.10 of
the kernel.org release <https://kernel.org/>). The variant is distinct
enough to warrant its own patch, as it operates in a different function
with a different trigger path that survives the existing fix.

If there is an existing patch that apparently has not made it's way to
Ubuntu distributions, we'd greatly appreciate if you could flag so that we
may initiate the CVE assignment process with kernel.org CNA.

We've attached our full technical report, and are here to answer any
questions.

Best regards,

<https://www.vulncheck.com/>

Wade Sparks III
VulnCheck
Senior Vulnerability Analyst

[-- Attachment #1.2: Type: text/html, Size: 3027 bytes --]

[-- Attachment #2: Unpatched skb_segment() Fragnesia Variant with Public PoC.md --]
[-- Type: text/markdown, Size: 3026 bytes --]

### 

### Unpatched skb\_segment() Fragnesia Variant with Public PoC

V12 Security [published a PoC](https://github.com/v12-security/pocs/tree/main/fragnesia-5db89c99566fc) on GitHub for a Fragnesia (CVE-2026-46300) variant that gets the same page-cache write through \`skb\_segment()\` instead of \`skb\_try\_coalesce()\`. The Fragnesia patch (\`f84eca581739\`) only fixed the coalesce path — nobody audited segmentation. The variant is unpatched in mainline as of 2026-05-15, which V12 [notes explicitly](https://github.com/v12-security/pocs/tree/main/fragnesia-5db89c99566fc) in their public GitHub write-up.

VulnCheck researchers tested the public PoC on the latest Ubuntu version on 2026-05-27 and determined the PoC works, though notably it has the same caveats as the original vulnerability (i.e., AppArmor would stop exploitation on a modern system). This variant appears to require its own unique CVE and patch: The vulnerability is in a different function with a different trigger path that independently survives the Fragnesia patch. \`skb\_segment()\` has to propagate \`SKBFL\_SHARED\_FRAG\` from frag\_list members, not just the head.

### Vulnerability Deconfliction

Fragnesia's bug is in \`skb\_try\_coalesce()\` when coalescing frags from a donor skb, the \`SKBFL\_SHARED\_FRAG\` flag doesn't get copied over.

V12's bug is in \`skb\_segment()\` — when building GSO segments from an skb that has a \`frag\_list\`, the flag only gets propagated from the head skb. If a frag\_list member is the one carrying page-cache frags (and thus the flag), it gets silently dropped during segmentation.

Same file (\`net/core/skbuff.c\`), same flag, same oversight pattern, different function.

### V12 Security PoC Analysis

The V12 Security PoC sets up three namespaces instead of our two. The sender fires \`send()\` \+ \`splice()\` back-to-back on the same TCP socket. GRO on the middle (forwarding) namespace coalesces both into one skb the send data becomes the head (no shared-frag flag), the splice data goes into frag\_list (flag set). They disable GSO on the egress veth so \`skb\_segment()\` runs and builds fresh segment skbs, copying the flag only from head. Segments hit the espintcp receiver, in-place decrypt fires on the page-cache page.

More moving parts than the original trigger (extra namespace, GRO coalescing has to land, GSO-off on the right interface) but still reliable: Back-to-back sends coalesce in the same NAPI poll cycle almost every time, and they retry on miss.

Once they have the page-cache write primitive, the rest diverges from the original approach:

\- They target a SUID binary (\`su\`/\`mount\`/\`passwd\`/\`chsh\`) instead of \`/etc/passwd\`  
\- They overwrite the ELF with a 120-byte \`setuid(0)+execve("/bin/sh")\` payload  
\- They run the corrupted SUID binary to get root, vs our \`su \-\` with empty password  
\- Same \`drop\_caches\` cleanup, same userns requirement

The underlying primitive is identical, though: AES-GCM keystream XOR, one byte per trigger.  

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-05-29  6:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-28 15:12 Unidentified Fragnesia Variant with Public PoC Wade Sparks
2026-05-28 16:16 ` Andrew Lunn
     [not found]   ` <CAA1v+SiTtZA74PONT8vsipoze7ZpdxncRO3vMNjRWy=jsRoDKA@mail.gmail.com>
2026-05-28 19:22     ` Greg KH
2026-05-29  6:37 ` Jiayuan Chen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox