Re: [PATCH net v3 1/1] net: ip_tunnel: reject excessive tunnel stacking headroom

Ido Schimmel <[email protected]> Tue, 4 Aug 2026 15:07:53 +0300
Newsgroups gmane.linux.network
Message-ID <20260804120753.GA1073788@shredder>
On Sun, Aug 02, 2026 at 06:49:17PM +0000, Zihan Xi wrote:
> raw_send_hdrinc() and rawv6_send_hdrinc() reserve LL headroom before
> storing skb header offsets in 16-bit fields. If an egress device has a
> very large LL_RESERVED_SPACE(), skb_reset_network_header() stores a
> truncated network_header offset and the hdrincl path can later copy the
> user header to the wrong location.
> 
> The reproducer creates a very deep gretap stack. Each new tunnel derives
> its needed_headroom from the lower device, so the stack can grow the
> resulting LL headroom beyond what skb header offsets can represent.
> 
> Reject IPv4 tunnel configurations when the computed headroom would make
> LL_RESERVED_SPACE() exceed the skb header offset range needed by raw
> IPv4 hdrincl. This rejects the bad tunnel stack at configuration time
> instead of checking every packet in later hot paths. Keep small raw IPv4
> and IPv6 hdrincl guards as a final bound check for devices that are not
> created through the IPv4 tunnel control path.
> 
> Fixes: 1a37e412a022 ("net: Use 16bits for *_headers fields of struct skbuff")
> Cc: [email protected]
> Reported-by: Vega <[email protected]>
> Assisted-by: Codex:gpt-5.4
> Signed-off-by: Zihan Xi <[email protected]>
> ---
> changes in v3:
>   - Rework the fix to reject excessive IPv4 tunnel headroom at
>     configuration time, following Willem de Bruijn's feedback.
>   - Drop the broad skb/XFRM/GSO/ESP/IPTFS runtime checked-helper changes
>     from v2.
>   - Keep only small raw hdrincl guards as a final bound check.
>   - v2 Link: https://lore.kernel.org/all/[email protected]/
> changes in v2:
>   - Keep skb_segment() default error code after successful checked skb offset
>     updates to avoid returning ERR_PTR(0), as reported by the kernel test
>     robot.
>   - Extend the checked update coverage to XFRM, ESP offload, and IPTFS
>     transport-header recomputation paths instead of relying on raw hdrincl
>     entry guards alone.
>   - v1 Link: https://lore.kernel.org/all/[email protected]/
> ---
>  include/net/ip_tunnels.h |   5 +-
>  net/ipv4/ip_gre.c        |   8 +--
>  net/ipv4/ip_tunnel.c     | 138 ++++++++++++++++++++++++++-------------
>  net/ipv4/ip_vti.c        |   4 +-
>  net/ipv4/ipip.c          |   4 +-
>  net/ipv4/raw.c           |   3 +
>  net/ipv6/raw.c           |   4 ++
>  7 files changed, 111 insertions(+), 55 deletions(-)

The patch conflicts with another patch from nebusec.ai:

https://lore.kernel.org/netdev/0ae4aa29223b89049727aec4d36f144bad41537e.1785476387.git.zhilinz@nebusec.ai/

nebusec.ai cannot send conflicting patches and make it our problem to
sort it out. I think we should proceed with the patch I mentioned and
drop this one. The current patch doesn't handle IPv6 tunnels.

Related, please make sure the team is aware of:

https://lore.kernel.org/all/83360de7addb13a3b5f4d5e722148f248fdb2ae0.1784884817.git.pabeni@redhat.com/

Thanks