CVE-2026-80906net: packet: 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: packet: fix wrong transport_header when sending VLAN-tagged frame In packet_parse_headers(), when processing a VLAN-tagged frame, skb_set_network_header() is called 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 the outer VLAN EtherType (e.g. 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 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_probe_transport_header() to before skb_set_network_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header, so nhoff correctly points to the VLAN header. The flow dissector can then 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) | from c2137d565ceb505de69593c181a0543bc4083838 before a4b82de96d465ddb44bc931145c0fa80c4fe9c9c; from 9ff46c36df2e0a1ac352f2f4038eaf3f0f7361b8 before fa86bc52ea8ba981f74f851fd61e2a3d3bc0feac; from dfed913e8b55a0c2c4906f1242fd38fd9a116e49 before 5479eb9b355f44745d7ccfe112386bd4f96eceea; from dfed913e8b55a0c2c4906f1242fd38fd9a116e49 before e451e20adb869a983a21dda158625f024142e61f; from dfed913e8b55a0c2c4906f1242fd38fd9a116e49 before 6971cf319263d6a1b4096f9248aca9e57d77a1eb; from dfed913e8b55a0c2c4906f1242fd38fd9a116e49 before f9297abbcaba760b7a7b9d63b839f607f738013e; from dfed913e8b55a0c2c4906f1242fd38fd9a116e49 before 6386a6ffa2efba2965ed8e4fa303582c0b76a215; from dfed913e8b55a0c2c4906f1242fd38fd9a116e49 before 01fdecc0480d916c799dbee584833a4a37e94d06; and 4 more ranges | CNA record |
References
- https://git.kernel.org/stable/c/a4b82de96d465ddb44bc931145c0fa80c4fe9c9c
- https://git.kernel.org/stable/c/fa86bc52ea8ba981f74f851fd61e2a3d3bc0feac
- https://git.kernel.org/stable/c/5479eb9b355f44745d7ccfe112386bd4f96eceea
- https://git.kernel.org/stable/c/e451e20adb869a983a21dda158625f024142e61f
- https://git.kernel.org/stable/c/6971cf319263d6a1b4096f9248aca9e57d77a1eb
- https://git.kernel.org/stable/c/f9297abbcaba760b7a7b9d63b839f607f738013e
- https://git.kernel.org/stable/c/6386a6ffa2efba2965ed8e4fa303582c0b76a215
- https://git.kernel.org/stable/c/01fdecc0480d916c799dbee584833a4a37e94d06
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.