Re: [PATCH net v2] net: iptunnel: fix stale transport header after GRE/TEB decap

[Paolo Abeni <pabeni@redhat.com>]

On 4/19/26 3:01 PM, Jiayuan Chen wrote:
> [...]
>>>   +662,18 @@ static inline int iptunnel_pull_offloads(struct sk_buff *skb)
>>>          return 0;
>>>   }
>>>
>>> +static inline void iptunnel_rebuild_transport_header(struct sk_buff *skb)
>>> +{
>>> +       if (!skb_is_gso(skb))
>>> +               return;
>>> +
>>> +       skb->transport_header = (typeof(skb->transport_header))~0U;
>>> +       skb_probe_transport_header(skb);
>>> +
>>> +       if (!skb_transport_header_was_set(skb))
>>> +               skb_gso_reset(skb);
>> I do not think this makes sense.
>> What is a valid case for this packet being processed further?
>> The buggy packet must be dropped, instead of being mangled like this.
> Hi Eric,
> 
> The reproducer builds a gre frame whose inner Ethernet header is 
> all-zero. Tracing the skb through RX:
> 
> 1. At GRE decap exit, skb_transport_offset(skb) < 0 is the rule, not the 
> exception.
> 
> It is negative for every packet leaving the tunnel, including perfectly 
> well-formed inner IPv4 traffic
> because the tunnel leaves skb->transport_header at the outer L4 offset while
> pskb_pull() has already advanced skb->data past it. 

Is it? the transport header is an offset on top of skb->head, pskb_pull
changes head only if the header is not in the linear part (and the
transport offset is already invalid).

> skb_transport_header_was_set() stays true, so downstream
> code that trusts that flag now trusts a stale, negative offset.
> 
> 2. GRO repairs it — but only for protocols it knows.
> 
> In dev_gro_receive(), skb->protocol is dispatched through the offload 
> table. For ETH_P_IP,
> inet_gro_receive() calls skb_set_transport_header(skb, 
> skb_gro_offset(skb)), and the offset
> becomes valid again. But for malformed skb, dev_gro_receive just bypass it.

So only malformed packets cause trouble, right?

> 3. Both kinds then reach __netif_receive_skb_core().
> 
> So the skb that qdisc/tc/BPF segmenters later see has an
> invariant violation — _was_set == true but offset < 0 — that the core
> layer has no intention of catching for us.
> 
> My reading of this is that the tunnel decap path is producing an skb 
> that doesn't
> honor the contract __netif_receive_skb_core() expects from its 
> producers, and that
> it doesn't really make sense to ask GRE to parse or validate the inner 
> L4 in order
> to fix this.
> 
> I'm thinking at the end of GRE decap, before handing the skb to 
> gro_cells_receive(),
> call skb_reset_transport_header(skb).

My take is that you need to address the issue earlier than the current
patch, dropping the malformed packets.

/P