{"cve":"CVE-2026-98954","nvd":{"published":"2026-10-23T13:17:16.600","modified":"2026-10-23T13:17:16.600","status":"Received","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet: always dissect GSO packets in __virtio_net_hdr_to_skb()\n\nCommit 9e8db5913264 (\"net: avoid false positives in untrusted gso\nvalidation\") added a '&& skb->network_header' check before flow-dissecting\nGSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in\n__virtio_net_hdr_to_skb(), because some callers (such as tun_get_user(),\ntun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called\nvirtio_net_hdr_*_to_skb() before initializing skb->network_header and\nskb->dev.\n\nBecause __alloc_skb() and __build_skb_around() zero-initialize\nskb->network_header to 0 (unlike mac_header and transport_header which\nare initialized to ~0U), those four callers always had\nskb->network_header == 0 and bypassed flow dissection in\n__virtio_net_hdr_to_skb(). More generally, skb->network_header is an\noffset from skb->head (where 0 is also a valid offset whenever\nskb_headroom(skb) is 0), not a boolean flag.\n\nWhenever the 'if (gso_type && skb->network_header)' branch was skipped,\nthe fallback 'else if (gso_type)' only pulled nh_min_len + thlen (40 bytes\nfor TCPv4) without dissecting the packet, without validating ip_proto or\nn_proto, and without setting skb->transport_header.\n\nIf the packet has a malformed network header, it is not rejected and a\nsubsequent skb_probe_transport_header() also fails, leaving\nskb->transport_header at ~0U (0xffff). Similarly, if an IPv4 packet\ncarries IP options (ihl > 5) or an IPv6 packet carries extension headers,\npulling only nh_min_len + thlen can leave the TCP header outside\nskb->head. In both cases, tcp_hdrlen(skb) in skb_gso_transport_seglen()\nreads out-of-bounds:\n\n  BUG: KASAN: slab-out-of-bounds in skb_gso_transport_seglen\n  Read of size 2 by task poc/133\n  skb_gso_transport_seglen (net/core/gso.c:155)\n  skb_gso_validate_mac_len (net/core/gso.c:270)\n  tbf_enqueue (net/sched/sch_tbf.c:260)\n  dev_qdisc_enqueue (net/core/dev.c:4227)\n  __dev_queue_xmit (net/core/dev.c:4884)\n\nIn addition, checking virtio_net_hdr_match_proto() only inside\n'if (!skb->protocol)' before flow dissection both skipped validation when\nskb->protocol was pre-set by the caller and rejected VLAN-tagged frames\nwhose outer L2 protocol is ETH_P_8021Q or ETH_P_8021AD.\n\nFix this by:\n1. Initializing skb->dev and skb->network_header (plus skb->protocol for\n   IFF_TUN) before virtio_net_hdr_*_to_skb() in tun_get_user(),\n   tun_xdp_one(), virtnet_receive_done(), and raw_verify_header(). In\n   tun_get_user(), drop the redundant skb_reset_mac_header(skb) in the\n   IFF_TUN case since __virtio_net_hdr_to_skb() unconditionally resets\n   mac_header.\n2. Removing '&& skb->network_header' and the unvalidated\n   'else if (gso_type)' fallback in __virtio_net_hdr_to_skb() so all GSO\n   packets without VIRTIO_NET_HDR_F_NEEDS_CSUM are flow-dissected, have\n   their transport header pulled into linear data, and have\n   skb->transport_header set.\n3. Moving the virtio_net_hdr_match_proto() check to after\n   skb_flow_dissect_flow_keys_basic(), validating keys.basic.n_proto\n   against hdr_gso_type.","cvss_v4":null,"cvss_v3":null,"cwes":[],"references":["https://git.kernel.org/stable/c/44378d02c5aaae24b60a75fbbb539b4aa4db503d","https://git.kernel.org/stable/c/5f4dfdf0077730e9d3ef5b37ceb17a5a56d6f34c"],"products":[],"source":"nvd","synced_at":"2026-10-23T16:39:28.036610720+00:00"},"epss":{"cve":"CVE-2026-98954","score":0.00173,"percentile":0.06683,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}