CVE-2026-80905: net: tap: fix wrong transport_header when sending VLAN-tagged frame
In the Linux kernel, the following vulnerability has been resolved:
net: tap: fix wrong transportheader when sending VLAN-tagged frame
In tapgetuserxdp(), when processing a VLAN-tagged frame (e.g. ETHP8021Q), skbsetnetworkheader() is called first to advance networkheader past the VLAN tag to the inner protocol header. skbprobetransportheader() is then called with skb->protocol still set to ETHP8021Q, while nhoff (derived from skbnetworkoffset()) already points past the VLAN tag to the inner protocol header.
In skbflowdissect(), proto is initialized to ETHP8021Q and nhoff points past the VLAN tag. When the dissector hits case ETHP8021Q, it reads a struct vlanhdr at the current nhoff via skbheaderpointer(), 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 skbprobetransportheader() never calls skbsettransportheader(), leaving transportheader at its uninitialized sentinel value (~0U).
Move skbsetnetworkheader() to after skbprobetransportheader(). At the time skbprobetransportheader() is called, networkheader still points to the VLAN header (offset ETHHLEN), 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 transportheader to be set correctly.
Event History
Frequently Asked Questions
What traffic path is affected?
The issue occurs in the Linux kernel TAP transmit path, specifically in tap_get_user_xdp() while processing VLAN-tagged Ethernet frames such as ETH_P_8021Q frames.
What condition triggers the faulty header handling?
A VLAN-tagged frame must be sent through TAP. The network-header offset has already advanced past the VLAN tag while the skb protocol still identifies the frame as VLAN-tagged, causing the flow dissector to interpret the inner protocol header as a VLAN header.
What is the immediate result of triggering the bug?
Transport-header discovery fails, so skb_probe_transport_header() does not set the transport_header field. The field remains at its uninitialized sentinel value of ~0U.
What change resolves the issue?
The fix moves skb_set_network_header() until after skb_probe_transport_header(), allowing transport-header probing to process the VLAN header at the correct offset.