ACK: [SRU][R/Q/N/J][PATCH 0/4] CVE-2026-46300

[Alessio Faina]

On Fri, May 22, 2026 at 02:44:49PM +0300, Cengiz Can wrote:
> https://ubuntu.com/security/CVE-2026-46300
> 
> [ Impact ]
> 
> Two skbuff helpers fail to propagate the SKBFL_SHARED_FRAG bit when
> they transfer paged fragments between skbs. The destination skb keeps
> a reference to the same externally-owned (or page-cache-backed) pages
> while reporting skb_has_shared_frag() as false.
> 
> That mismatch is the consumer-side blind spot exploited by V12
> Security's "Fragnesia" PoC family (CVE-2026-46300). The PoCs route a
> crafted ESP packet through a code path that drops the SHARED_FRAG bit
> (skb_try_coalesce on the espintcp ULP receive path; skb_segment on the
> GSO segmentation path), then deliver it to esp_input(). The
> CVE-2026-43284 consumer-side gate (f4c50a4034e6 "xfrm: esp: avoid
> in-place decrypt on shared skb frags") sees skb_has_shared_frag() as
> false and decrypts in place over a page-cache page. An unprivileged
> local user can use this primitive to corrupt /usr/bin/su or other
> root-owned read-only files, yielding local privilege escalation.
> 
> [ Fix ]
> 
> Two patches and a curious prerequisite.
> 
> Fragnesia fixes depend on commit f4c50a4034e6 (the upstream fix for
> CVE-2026-43284) being present on the tree. That commit is both the
> introducer of the SHARED_FRAG consumer-side gate (the only in-tree
> reader of the bit at the time of writing) and the enabler of any
> meaningful behaviour from the two skbuff patches in this series.
> So yes, you read it right: f4c50a4034e6 is both the cause and the
> remedy here. *takes a deep breath* Without it the marker has no
> observer and the patches here are effectively no-ops. With it
> present, the patches close the producer-side gap so the consumer-
> side gate is no longer fooled.
> 
>   commit f84eca5817390257cef78013d0112481c503b4a3
>     ("net: skbuff: preserve shared-frag marker during coalescing")
>     Sets SKBFL_SHARED_FRAG on the destination of skb_try_coalesce()
>     whenever paged frags were actually transferred.
> 
>   commit 48f6a5356a33dd78e7144ae1faef95ffc990aae0
>     ("net: skbuff: propagate shared-frag marker through frag-transfer helpers")
>     Folds the source's SHARED_FRAG flag into the destination in
>     __pskb_copy_fclone(), skb_shift(), skb_gro_receive(),
>     skb_gro_receive_list(), skb_segment() and tcp_clone_payload().
> 
> Both commits are in linux-next / netdev "net" branch at submission
> time.
> 
> [ Test Plan ]
> 
> The full V12 Security "Fragnesia" PoC family is run on a VM booted
> with the patched kernel image:
> 
>   PoC variant 1 (espintcp coalesce-strip):
>     github.com/v12-security/pocs/fragnesia
>   PoC variant 2 (skb_segment GSO frag-strip):
>     github.com/v12-security/pocs/fragnesia-5db89c99566fc
> 
> For each variant: capture sha256(/usr/bin/su) pre-run, run the PoC
> binary for up to 180 s, then capture sha256(/usr/bin/su) post-run.
> 
> Both PoC variants depend on CLONE_NEWNET from an unprivileged user
> to set up the espintcp / GSO topology. That syscall is gated by
> the apparmor_restrict_unprivileged_userns sysctl, which ships
> enabled by default on noble and later (jammy did not have this
> restriction). To assess the kernel-side fix on its own terms and
> not lean on AppArmor as a mitigation, the restriction is
> deliberately disabled for the test
> (kernel.apparmor_restrict_unprivileged_userns=0) on noble,
> questing and resolute. Jammy needs no action.
> 
> Jammy, noble, questing and resolute with f4c50a4034e6 and
> f84eca581739 + 48f6a5356a33 applied verified to be immune to V12's
> Fragnesia PoCs.
> 
> [ Where Problems Could Occur ]
> 
> These patches only set a flag bit on packet metadata. They do not
> change packet payloads, lifetimes, routing, or any user-visible
> behaviour. The bit was already supposed to be set on these code
> paths and was simply being lost in transit.
> 
> In the worst case a bug here would cause a network packet to be
> copied once more than strictly necessary before encryption. That
> is a tiny performance loss in an uncommon path, not a crash or a
> correctness problem. The opposite mistake (forgetting to set the
> bit somewhere we should have) just re-exposes the original CVE,
> it does not introduce a new failure mode.
> 
> Regression risk: very low. Network throughput regression: not
> expected. Boot or stability impact: none expected.
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

Acked-by: Alessio Faina <alessio.faina at canonical.com>