Re: [PATCH net v3 1/1] net: ip_tunnel: reject excessive tunnel stacking headroom
zihan xi <[email protected]> Tue, 4 Aug 2026 20:29:30 +0800
| Newsgroups | gmane.linux.network |
|---|---|
| Message-ID | <CAANe3eT3u8KDnSjmiAanAMQRHt60WaQ_qGz_gMK=yYRwfDxcDw@mail.gmail.com> |
On Tue, Aug 4, 2026 at 8:08 PM Ido Schimmel <[email protected]> wrote: > > 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 Hi Ido, Thanks for pointing this out, and sorry for the confusion. You are right, these two patches address the same headroom issue and should not have been sent as competing fixes from the same team. Let's proceed with Zhiling's patch and drop this series. We'll coordinate internally and follow up on that thread if any further changes are needed, including IPv6 tunnel coverage and Paolo's related patch. Thanks, Zihan