CVE-2026-80590

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

inet: frags: strip GSO state from fragments before reassembly

A virtionethdr (tun/tap, or AFPACKET with PACKETVNETHDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gsotype to fragoff. inetfragreasmprepare()/inetfragreasmfinish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gsosize/gsotype/gsosegs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with.

After ipdefrag() (iplocaldeliver(), nfdefragipv4, ...) the reassembled skb therefore still claims to be GSO (SKBGSODODGY), and the next software segmentation point - udprcvsegment() on local delivery, validatexmitskb(), or the ipfinishoutputgso() slow path - hands it to skbsegment(). skbsegment()'s fraglist walk assumes GRO-shaped input and hits one of its BUGON()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: <TASK> __udpgsosegment+0x29a/0x27d0 udp4ufofragment+0x458/0x6c0 inetgsosegment+0x429/0x1340 skbmacgso_segment+0x233/0x4f0 __skbgsosegment+0x308/0x660 udpqueuercvskb+0x440/0xad0 udpunicastrcvskb+0xc7/0x2c0 udprcv+0x16ce/0x2260 ipprotocoldeliverrcu+0x197/0x2d0 iplocaldeliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netifreceiveskbonecore+0x15e/0x1c0 __netifreceiveskb+0x1e/0x110 netifreceiveskb+0xf6/0x5c0 tunrxbatched.isra.0+0x3ab/0x790 tungetuser+0x17c3/0x3550 tunchrwriteiter+0xba/0x1b0 vfswrite+0x646/0x1130 </TASK> 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 CAPNETRAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtionethdr to a tap. The SKBGSODODGY fraglist checks added by commit 3dcbdb134f32 ("net: gso: Fix skbsegment splat when splitting gsosize mangled skb having linear-headed fraglist") and by commit 9e4b7a99a03a ("net: gso: fix panic on fraglist with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gsosize == 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 virtionethdr"), 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 inetfragqueueinsert(), which IPv4, IPv6, nfconntrackreasm and 6lowpan reassembly share; then neither the head nor the fraglist members of the reassembled skb carry them (the members matter too: the ipdofragment()/ip6fragment() fast paths send them out as they are). The head may remain CHECKSUMPARTIAL; that is already accepted on receive and resolved by skbchecksumhelp() in ipdofragment()/ip6_fragment() on forward.

Tested on top of net.git (dc4b95b8fee9), x8664: the tap reproducer above, two further IPv4 fraglist geometries that reach BUGON(i >= nfrags) and BUGON(!listskb->headfrag), and an IPv6 fragment-header variant (udp6ufofragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.