Re: [PATCH net v2 1/1] net: skbuff: reject skb header offset updates that truncate

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Zihan Xi wrote:
> raw_send_hdrinc() and rawv6_send_hdrinc() reserve LL headroom before
> storing skb header offsets in 16-bit fields. If the reserved headroom
> grows past the representable range, skb_reset_network_header() truncates
> the stored offset and the hdrincl path later copies the user header to
> the wrong location.
> 
> On IPv4 this can also happen after the user header is copied, because the
> transport header is advanced by iphlen. The value U16_MAX itself is not a
> valid transport header offset either, because it is used as the unset
> sentinel.
> 
> The initial raw route is not the only place that matters. LOCAL_OUT can
> reroute the skb, XFRM can add dst->header_len, and LWT or other output
> paths can grow the skb head later. More generally, positive calls into
> skb_headers_offset_update() can wrap these 16-bit offsets, while later
> paths that recompute transport_header from network_header can still
> overflow it or turn it into the U16_MAX sentinel.
> 
> Reject hdrincl sends when the initial reserved LL headroom cannot fit in
> the skb header offset fields, and reject later positive skb header offset
> updates or transport-header recomputations before they would overflow the
> stored 16-bit values.
> 
> Fixes: 1a37e412a022 ("net: Use 16bits for *_headers fields of struct skbuff")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Assisted-by: Codex:gpt-5.4
> Signed-off-by: Zihan Xi <zihanx@nebusec.ai>

This is an enormous amount of code change, including in the hot path,
for a rare edge case.

Can we instead address this at the source at control time. E.g., fail
GRETAP (or similar) stacking if it exceeds a safe headroom?

The patch also seems to combine multiple paths. It mentions raw (and
those changes are fairly small), but then also adds checks to XFRM.
That should likely be a separate patch. If needed at all. As said,
hopefully we can catch this by restricting the bad configurations,
rather than by testing each packet over such a configuration.