CVE-2026-80590

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: frags: strip GSO state from fragments before reassembly<br /> <br /> A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark<br /> an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.<br /> inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first<br /> fragment&amp;#39;s skb as the head of the reassembled datagram, including its<br /> shinfo-&gt;gso_size/gso_type/gso_segs, and chain the remaining fragments<br /> on frag_list with whatever linear/paged layout they arrived with.<br /> <br /> After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the<br /> reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and<br /> the next software segmentation point - udp_rcv_segment() on local<br /> delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow<br /> path - hands it to skb_segment(). skb_segment()&amp;#39;s frag_list walk<br /> assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to<br /> a tap by an unprivileged user in its own userns are enough:<br /> <br /> kernel BUG at net/core/skbuff.c:4899!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2<br /> RIP: 0010:skb_segment+0x20ca/0x48b0<br /> Call Trace:<br /> <br /> __udp_gso_segment+0x29a/0x27d0<br /> udp4_ufo_fragment+0x458/0x6c0<br /> inet_gso_segment+0x429/0x1340<br /> skb_mac_gso_segment+0x233/0x4f0<br /> __skb_gso_segment+0x308/0x660<br /> udp_queue_rcv_skb+0x440/0xad0<br /> udp_unicast_rcv_skb+0xc7/0x2c0<br /> udp_rcv+0x16ce/0x2260<br /> ip_protocol_deliver_rcu+0x197/0x2d0<br /> ip_local_deliver+0x430/0x690<br /> ip_rcv+0x16f/0x1f0<br /> __netif_receive_skb_one_core+0x15e/0x1c0<br /> __netif_receive_skb+0x1e/0x110<br /> netif_receive_skb+0xf6/0x5c0<br /> tun_rx_batched.isra.0+0x3ab/0x790<br /> tun_get_user+0x17c3/0x3550<br /> tun_chr_write_iter+0xba/0x1b0<br /> vfs_write+0x646/0x1130<br /> <br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> This runs with BH disabled, so it is a panic rather than an oops. The<br /> same is reachable with CAP_NET_RAW in a netns where a defrag point<br /> precedes a GSO point, and from a guest whose VMM forwards<br /> virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by<br /> commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting<br /> gso_size mangled skb having linear-headed frag_list") and by<br /> commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head<br /> alloc types") do not cover it: page-backed heads skip them, and kmalloc<br /> heads skip them when gso_size == skb_headlen(head), which the sender<br /> controls.<br /> <br /> An skb entering a frag queue is an IP fragment by definition and<br /> cannot legitimately carry GSO state: GRO does not merge fragments and<br /> the stack segments before it fragments, so only untrusted sources are<br /> affected. This has been reachable since<br /> commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), the first<br /> path that let userspace attach GSO metadata to an IP fragment. Reset<br /> the GSO fields of every fragment as it is queued, in<br /> inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and<br /> 6lowpan reassembly share; then neither the head nor the frag_list<br /> members of the reassembled skb carry them (the members matter too:<br /> the ip_do_fragment()/ip6_fragment() fast paths send them out as they<br /> are). The head may remain CHECKSUM_PARTIAL; that is already accepted<br /> on receive and resolved by skb_checksum_help() in<br /> ip_do_fragment()/ip6_fragment() on forward.<br /> <br /> Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer<br /> above, two further IPv4 frag_list geometries that reach<br /> BUG_ON(i &gt;= nfrags) and BUG_ON(!list_skb-&gt;head_frag), and an IPv6<br /> fragment-header variant (udp6_ufo_fragment()) each panic the unpatched<br /> kernel; with this patch all four datagrams are delivered intact and<br /> nothing is logged.