In the Linux kernel, the following vulnerability has been resolved:

inet: frags: strip GSO state from fragments before reassembly

A virtio net hdr (tun/tap, or AF PACKET with PACKET VNET HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso type to frag off. inet frag reasm prepare()/inet frag reasm finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso size/gso type/gso segs, and chain the remaining fragments on frag list with whatever linear/paged layout they arrived with.

After ip defrag() (ip local deliver(), nf defrag ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB GSO DODGY), and the next software segmentation point - udp rcv segment() on local delivery, validate xmit skb(), or the ip finish output gso() slow path - hands it to skb segment(). skb segment()'s frag list walk assumes GRO-shaped input and hits one of its BUG ON()s. Two writes to a tap by an unprivileged user in its own userns are enough:

kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb segment+0x20ca/0x48b0 Call Trace: udp gso segment+0x29a/0x27d0 udp4 ufo fragment+0x458/0x6c0 inet gso segment+0x429/0x1340 skb mac gso segment+0x233/0x4f0 skb gso segment+0x308/0x660 udp queue rcv skb+0x440/0xad0 udp unicast rcv skb+0xc7/0x2c0 udp rcv+0x16ce/0x2260 ip protocol deliver rcu+0x197/0x2d0 ip local deliver+0x430/0x690 ip rcv+0x16f/0x1f0 netif receive skb one core+0x15e/0x1c0 netif receive skb+0x1e/0x110 netif receive skb+0xf6/0x5c0 tun rx batched.isra.0+0x3ab/0x790 tun get user+0x17c3/0x3550 tun chr write iter+0xba/0x1b0 vfs write+0x646/0x1130 Kernel panic - not syncing: Fatal exception in interrupt

This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP NET RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio net hdr to a tap. The SKB GSO DODGY frag list checks added by commit 3dcbdb134f32 ("net: gso: Fix skb segment splat when splitting gso size mangled skb having linear-headed frag list") and by commit 9e4b7a99a03a ("net: gso: fix panic on frag list with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso size == skb headlen(head), which the sender controls.

An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 ("tun: Allow GSO using virtio net hdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet frag queue insert(), which IPv4, IPv6, nf conntrack reasm and 6lowpan reassembly share; then neither the head nor the frag list members of the reassembled skb carry them (the members matter too: the ip do fragment()/ip6 fragment() fast paths send them out as they are). The head may remain CHECKSUM PARTIAL; that is already accepted on receive and resolved by skb checksum help() in ip do fragment()/ip6 fragment() on forward.

Tested on top of net.git (dc4b95b8fee9), x86 64: the tap reproducer above, two further IPv4 frag list geometries that reach BUG ON(i >= nfrags) and BUG ON(!list skb->head frag), and an IPv6 fragment-header variant (udp6 ufo fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.