A leftover giant-packet mark on an IP fragment can panic the host
Brief
Two writes into a tap from an unprivileged user in its own namespace are enough, and the crash runs with bottom halves off, so the host panics instead of oopsing.
Notes
Landed on Linus in merge 1b78070aaef6 (net-7.3-rc1, 2026-08-27).
d5dc1e69fd72 (Xinyang Ge): an IP fragment queued for reassembly still carried giant-packet (GSO) metadata from virtio_net_hdr. After defrag the reassembled datagram still claimed SKB_GSO_DODGY, and skb_segment() hit a BUG_ON. The GSO fields are now reset in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm, and 6lowpan share. Fixes: f43798c27684 (tun: Allow GSO using virtio_net_hdr). Cc: stable.
Suggested-by Eric Dumazet. Reviewed-by Eric Dumazet. Signed-off-by Paolo Abeni and Jakub Kicinski.
Public text is a host panic from a leftover GSO mark, not a named CVE. Same path from a guest whose VMM forwards virtio_net_hdr to a tap. Also reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point.
Same pull, do not split-file: HTB classify hop limit, qdisc packet-length bound, bridge multicast UAF, SLIP hangup UAF, device TLS frag OOB write, TCP-AO current_key UAF, virtio-net gso_segs overflow.
Weekly tags already live as 53d122ae. Do not fold the nf-26-08-27 control-plane hygiene into this card.
Commit d5dc1e69fd7258ea605c9952e5d5947539159ae3