Thread (5 messages) flat view 5 messages, 3 authors, 9d ago

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

From: zihan xi <hidden>
Date: 2026-08-04 12:29:56

On Tue, Aug 4, 2026 at 8:08 PM Ido Schimmel [off-list ref] wrote:
On Sun, Aug 02, 2026 at 06:49:17PM +0000, Zihan Xi wrote:
quoted
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: stable@vger.kernel.org
Reported-by: Vega <redacted>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zihan Xi <redacted>
---
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/cover.1785529351.git.zihanx@nebusec.ai/ (local)
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/cover.1785346409.git.zihanx@nebusec.ai/ (local)
---
 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/ (local)

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/ (local)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help