GHSA-27VC-2785-HFJH

Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31
VLAI
Details

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

net: always dissect GSO packets in __virtio_net_hdr_to_skb()

Commit 9e8db5913264 ("net: avoid false positives in untrusted gso validation") added a '&& skb->network_header' check before flow-dissecting GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in _virtio_net_hdr_to_skb(), because some callers (such as tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called virtio_net_hdr*_to_skb() before initializing skb->network_header and skb->dev.

Because __alloc_skb() and __build_skb_around() zero-initialize skb->network_header to 0 (unlike mac_header and transport_header which are initialized to ~0U), those four callers always had skb->network_header == 0 and bypassed flow dissection in __virtio_net_hdr_to_skb(). More generally, skb->network_header is an offset from skb->head (where 0 is also a valid offset whenever skb_headroom(skb) is 0), not a boolean flag.

Whenever the 'if (gso_type && skb->network_header)' branch was skipped, the fallback 'else if (gso_type)' only pulled nh_min_len + thlen (40 bytes for TCPv4) without dissecting the packet, without validating ip_proto or n_proto, and without setting skb->transport_header.

If the packet has a malformed network header, it is not rejected and a subsequent skb_probe_transport_header() also fails, leaving skb->transport_header at ~0U (0xffff). Similarly, if an IPv4 packet carries IP options (ihl > 5) or an IPv6 packet carries extension headers, pulling only nh_min_len + thlen can leave the TCP header outside skb->head. In both cases, tcp_hdrlen(skb) in skb_gso_transport_seglen() reads out-of-bounds:

BUG: KASAN: slab-out-of-bounds in skb_gso_transport_seglen Read of size 2 by task poc/133 skb_gso_transport_seglen (net/core/gso.c:155) skb_gso_validate_mac_len (net/core/gso.c:270) tbf_enqueue (net/sched/sch_tbf.c:260) dev_qdisc_enqueue (net/core/dev.c:4227) __dev_queue_xmit (net/core/dev.c:4884)

In addition, checking virtio_net_hdr_match_proto() only inside 'if (!skb->protocol)' before flow dissection both skipped validation when skb->protocol was pre-set by the caller and rejected VLAN-tagged frames whose outer L2 protocol is ETH_P_8021Q or ETH_P_8021AD.

Fix this by: 1. Initializing skb->dev and skb->network_header (plus skb->protocol for IFF_TUN) before virtio_net_hdr_*_to_skb() in tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header(). In tun_get_user(), drop the redundant skb_reset_mac_header(skb) in the IFF_TUN case since __virtio_net_hdr_to_skb() unconditionally resets mac_header. 2. Removing '&& skb->network_header' and the unvalidated 'else if (gso_type)' fallback in __virtio_net_hdr_to_skb() so all GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM are flow-dissected, have their transport header pulled into linear data, and have skb->transport_header set. 3. Moving the virtio_net_hdr_match_proto() check to after skb_flow_dissect_flow_keys_basic(), validating keys.basic.n_proto against hdr_gso_type.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-98954"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-23T13:17:16Z",
    "severity": null
  },
  "details": "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 \u0027\u0026\u0026 skb-\u003enetwork_header\u0027 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-\u003enetwork_header and\nskb-\u003edev.\n\nBecause __alloc_skb() and __build_skb_around() zero-initialize\nskb-\u003enetwork_header to 0 (unlike mac_header and transport_header which\nare initialized to ~0U), those four callers always had\nskb-\u003enetwork_header == 0 and bypassed flow dissection in\n__virtio_net_hdr_to_skb(). More generally, skb-\u003enetwork_header is an\noffset from skb-\u003ehead (where 0 is also a valid offset whenever\nskb_headroom(skb) is 0), not a boolean flag.\n\nWhenever the \u0027if (gso_type \u0026\u0026 skb-\u003enetwork_header)\u0027 branch was skipped,\nthe fallback \u0027else if (gso_type)\u0027 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-\u003etransport_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-\u003etransport_header at ~0U (0xffff). Similarly, if an IPv4 packet\ncarries IP options (ihl \u003e 5) or an IPv6 packet carries extension headers,\npulling only nh_min_len + thlen can leave the TCP header outside\nskb-\u003ehead. 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\u0027if (!skb-\u003eprotocol)\u0027 before flow dissection both skipped validation when\nskb-\u003eprotocol 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-\u003edev and skb-\u003enetwork_header (plus skb-\u003eprotocol 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 \u0027\u0026\u0026 skb-\u003enetwork_header\u0027 and the unvalidated\n   \u0027else if (gso_type)\u0027 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-\u003etransport_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.",
  "id": "GHSA-27vc-2785-hfjh",
  "modified": "2026-10-23T15:31:32Z",
  "published": "2026-10-23T15:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98954"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/44378d02c5aaae24b60a75fbbb539b4aa4db503d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5f4dfdf0077730e9d3ef5b37ceb17a5a56d6f34c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.