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

[Jiayuan Chen]

On 4/23/26 4:19 PM, Paolo Abeni wrote:
> 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).


Sorry, my wording was imprecise. The point is not that `transport_header`
itself holds a negative value — it does not — but that after GRE processing,
`skb->data` has advanced past the outer L4 while `skb->transport_header`
is never touched, so `skb_transport_offset(skb)` ends up negative.

> > 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?
The negative offset is produced for every packet leaving GRE, not just
malformed ones. What differs is what happens downstream:

- For well-formed inner IPv4, `inet_gro_receive()` calls
 `skb_set_transport_header(skb, skb_gro_offset(skb))` and restores a
 valid offset before any consumer observes it.
- For malformed inner frames (e.g. `skb->protocol == ETH_P_802_2 or 
other `),
 `dev_gro_receive()` finds no ptype and just passes the skb through.
 The stale negative offset survives into `__netif_receive_skb_core()`.

So the UAF needs both conditions: GRE producing the stale offset *and*

no downstream rescue.


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


Dropping at tunnel decap is a reasonable option, e.g.:

  if (unlikely(skb->protocol == htons(ETH_P_802_2) ||
               skb->protocol == htons(ETH_P_802_3) ||
               ....)) {
      kfree_skb_reason(skb, SKB_DROP_REASON_...);
      return 0;
  }

Two concerns about this approach, though:

1.It asks GRE to decide whether an inner L2 frame is "sensible",
 which I don't think should be GRE's responsibility — GRE is a
 generic L2/L3 tunnel and historically stays agnostic about the
 inner payload.

2. More importantly, filtering on ETH_P_802_2 / ETH_P_802_3 only
 covers the case where inner h_proto < ETH_P_802_3_MIN. The same
 stale-offset condition can also be reached with any inner
 ethertype that has no GRO receive callback resetting
 transport_header.

In my earlier reply to Eric I suggested calling
skb_reset_transport_header(skb) at the tunnel decap exit instead.
A few reasons I think this is a cleaner fix:

1.It is inner-protocol agnostic — it normalizes the skb regardless
of what the inner ethertype happens to be, so ARP/PPPoE/... are
fixed by the same one-liner.

2.ip_tunnel_rcv() already updates mac_header (via eth_type_trans)
and network_header (ip_tunnel.c:414). transport_header is the
only one of the three left pointing at the outer offset; resetting
it here is completing what the function is already doing for the
other two.

3.Malformed frames that carry it downstream simply fail ptype_base
dispatch and are dropped there, the same way any unknown-ethertype
frame is dropped today.