net: always dissect GSO packets in __virtio_net_hdr_to_skb()

Summary

CVECVE-2026-98954
StatePUBLISHED
AssignerLinux
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-10-23 13:17:16 UTC
Updated2026-10-23 13:17:16 UTC
DescriptionIn 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.

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Linux Linux affected d5be7f632bad0f489879eed0ff4b99bd7fe0b74c 5f4dfdf0077730e9d3ef5b37ceb17a5a56d6f34c git Not specified
CNA Linux Linux affected d5be7f632bad0f489879eed0ff4b99bd7fe0b74c 44378d02c5aaae24b60a75fbbb539b4aa4db503d git Not specified
CNA Linux Linux affected dac7d4432b13d6b58923c1178b786bcda37c9e9e git Not specified
CNA Linux Linux affected e93384b12443c9bb6830b56b7d299beed432b865 git Not specified
CNA Linux Linux affected f709f7b28d76de327373598a0fda9f916c36b5e6 git Not specified
CNA Linux Linux affected d996573ebd5c528c613e90b7e7daa961d58fa16e git Not specified
CNA Linux Linux affected c375152be9dd9d6fbf6ae5ac8be337d0590f192a git Not specified
CNA Linux Linux affected 0dab7eb86ea06ce8c530785f1999948c6f223c96 git Not specified
CNA Linux Linux affected ea3fb2ce5fa794d02135f5c079e05cd6fc3f545d git Not specified
CNA Linux Linux affected 54ef8243c3c8e90f1ea5792e6752e021a25c8eb3 git Not specified
CNA Linux Linux affected 4.14.104 4.15 semver Not specified
CNA Linux Linux affected 4.19.26 4.20 semver Not specified
CNA Linux Linux affected 4.20.13 4.21 semver Not specified
CNA Linux Linux affected 4.14.226 4.15 semver Not specified
CNA Linux Linux affected 4.19.181 4.20 semver Not specified
CNA Linux Linux affected 5.0 Not specified
CNA Linux Linux unaffected 5.0 semver Not specified
CNA Linux Linux unaffected 7.2.11 7.2.* semver Not specified
CNA Linux Linux unaffected 7.3 * original_commit_for_fix Not specified

References

ReferenceSourceLinkTags
git.kernel.org/stable/c/44378d02c5aaae24b60a75fbbb539b4aa4db503d 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/5f4dfdf0077730e9d3ef5b37ceb17a5a56d6f34c 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis

© CVE.report 2026

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report