net: always dissect GSO packets in __virtio_net_hdr_to_skb()
CVSS score
—
EPSS probability
—
Risk score
—
Published
3 h ago
Resmî kaynaklarda yeterli kanıt bulunamadı. Bu sonuç “yama yok” anlamına gelmez.
Impact on My Inventory
Only the personal products you have added to your account are assessed; an organisation's inventory does not appear here.
Checking session…
Vulnerability description
DayBreach CVE AI Research
CVE-2026-98954 has vendor, distribution, patch and security-source records on file. We can compare them and prepare an explanation linked to the evidence.
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.
IMPACT: Affected Products and Software
RED HAT CSAF/VEX: Product Impact Check
SCORING: CVSS from Multiple Sources
CVSS Scores
The Common Vulnerability Scoring System is a standardised framework for assessing the severity of vulnerabilities in software and systems. We collect and display CVSS scores from several sources for each CVE.
| SCORE | VERSION | SEVERITY | VECTOR | SOURCE |
|---|---|---|---|---|
| The sources have not yet published a verified CVSS metric. | ||||
Patch and Remediation Guide
Solution & Remediation Advisory
İncelenen resmî kaynaklarda yama durumu doğrulanamadı. Bu sonuç “yama yok” anlamına gelmez.
Public exploit and active exploitation status
Verified exploit intelligence
No verified public PoC, exploit repository or Metasploit module has been found for this CVE yet.
Weakness Classification and Attack Patterns (CWE & CAPEC)
CWE - Common Weakness Enumeration
While CVE identifies specific instances of vulnerabilities, CWE categorises the common flaws or weaknesses that can lead to vulnerabilities. CVE-2026-98954 is associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2026-98954 weaknesses.
Official Sources and Advisories
Yama durumu bilinmiyor
Similar Vulnerabilities
Get this vulnerability through the API
Affected products, version ranges, exploitation status and patch information in a single request, with a free key.
curl -H "x-api-key: $DAYBREACH_API_KEY" \ "https://api.daybreach.dev/api/v1/intel/cves/CVE-2026-98954"