CVE-2026-80905net: tap: fix wrong transport_header when sending VLAN-tagged frame
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: net: tap: fix wrong transport_header when sending VLAN-tagged frame In tap_get_user_xdp(), when processing a VLAN-tagged frame (e.g. ETH_P_8021Q), skb_set_network_header() is called first to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to ETH_P_8021Q, while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header. In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at the current nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U). Move skb_set_network_header() to after skb_probe_transport_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header (offset ETH_HLEN), so nhoff is correct and the flow dissector can parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Sep 4, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | 8c76e77f9069f10505c08e02646c3ee11ad79038 builds before 5ffaa5d7f56ab24a8e23cf131eadfef31a3bbc4b; from 8c76e77f9069f10505c08e02646c3ee11ad79038 before 88b79ac89ecc04d7f2613f7e1c0b46f0c4ddb2f3; from 8c76e77f9069f10505c08e02646c3ee11ad79038 before cbb35cbe8db268fefe34c23df15348cf99025298; 3cae5ef1f37a475faf7c40bc6a3c170779f3e0b1; from 4.20.1 before 4.21 | CNA record |
References
- https://git.kernel.org/stable/c/5ffaa5d7f56ab24a8e23cf131eadfef31a3bbc4b
- https://git.kernel.org/stable/c/88b79ac89ecc04d7f2613f7e1c0b46f0c4ddb2f3
- https://git.kernel.org/stable/c/cbb35cbe8db268fefe34c23df15348cf99025298
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.