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

[Cengiz Can]

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.