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

[Jiayuan Chen <jiayuan.chen@linux.dev>]

[...]
>>   +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. 
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.

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).

Thanks,
Jiayuan