Description

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: <TASK> __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 </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 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.6",
  "pubDate": "2026-08-28T08:16:42.517Z",
  "pubdate": "2026-08-28T08:16:42.517Z",
  "executiveSummary": "A kernel panic vulnerability exists in the Linux kernel's network stack involving the handling of GSO (Generic Segmentation Offload) metadata within IP fragments.\nThe vulnerability allows an unprivileged user to trigger a kernel BUG_ON crash by injecting specially crafted IP fragments with malformed GSO headers via tun/tap or AF_PACKET interfaces.\nThe root cause is the improper retention of GSO state on reassembled packets, which subsequently violates the assumptions made by skb_segment() during local delivery or subsequent transmission paths.\nThe impact is a Denial of Service (DoS) resulting from a kernel panic when processing these fragments.\nThe vulnerability is accessible to unprivileged users within their own user namespaces and requires no special authentication, provided they have access to an interface that permits the injection of virtio_net_hdr headers.\nExposure affects systems where fragmentation reassembly points precede segmentation points, specifically impacting virtualized environments where VMMs pass through virtio_net_hdr metadata.",
  "technicalDetails": "The vulnerability originates in the interaction between the IP fragmentation reassembly logic and the GSO state management in the Linux network stack. Specifically, virtio_net_hdr (used by tun/tap and AF_PACKET) permits the association of GSO metadata—such as gso_size, gso_type, and gso_segs—with IP fragments. These fragments, when queued for reassembly, retain this GSO state in the sk_buff (skb) structures.\nDuring reassembly, inet_frag_reasm_prepare() and inet_frag_reasm_finish() preserve the first fragment's skb as the head of the reassembled datagram. Because this head and its associated frag_list members still carry GSO flags, the reassembled skb is incorrectly flagged as a GSO packet (e.g., SKB_GSO_DODGY).\nWhen this reassembled skb reaches a segmentation point (such as udp_rcv_segment(), validate_xmit_skb(), or ip_finish_output_gso()), the kernel invokes skb_segment() to split the packet. The skb_segment() function expects a specific packet layout consistent with GRO-merged buffers. Because the reassembled fragments do not conform to these expected structural invariants, the function triggers a BUG_ON() condition, resulting in a kernel panic.\nThe attack flow proceeds as follows: 1) An attacker utilizes a tun/tap interface or a raw socket (AF_PACKET) to inject fragments that include virtio_net_hdr metadata marked as GSO. 2) The Linux kernel's reassembly logic (inet_frag_queue_insert) accepts these fragments without stripping the GSO metadata. 3) The IP stack reassembles these fragments into a single skb, which now holds an inconsistent state (an IP-fragmented datagram masquerading as a GSO segment). 4) The stack subsequently attempts to process this datagram through a GSO segmentation path, leading to the internal BUG_ON() failure in net/core/skbuff.c.\nThe vulnerability is highly reachable for users with CAP_NET_RAW or those operating within a user namespace, as these environments allow for the manipulation of packet headers that bypass standard driver-level sanity checks. Even with existing mitigations like commit 3dcbdb134f32 and 9e4b7a99a03a, the flaw persists because specific head allocation types (page-backed or kmalloc-backed where gso_size matches the head length) circumvent existing fragment list sanity checks. The lack of proper GSO state sanitization during the insertion phase (inet_frag_queue_insert) ensures that the reassembled head and its list members remain inherently dangerous when handled by subsequent stack segments."
}