Re: [PATCH v2 net 2/2] net: tap: fix wrong transport_header when sending VLAN-tagged frame

Willem de Bruijn <[email protected]>
Newsgroups dev.linux.lists.imx,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <[email protected]>
wei.fang@ wrote:
> From: Wei Fang <[email protected]>
> 
> 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.
> 
> Fixes: 8c76e77f9069 ("tap: call skb_probe_transport_header after setting skb->dev")
> Assisted-by: WChat:claude-opus-4-8
> Signed-off-by: Wei Fang <[email protected]>

Reviewed-by: Willem de Bruijn <[email protected]>

Only if respinning: include the explanation why tap_get_user does not
need this, only tap_get_user_xdp.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.