From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Zihan Xi <zihanx@nebusec.ai>, netdev@vger.kernel.org
Cc: zihanx@nebusec.ai, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
steffen.klassert@secunet.com, herbert@gondor.apana.org.au,
dsahern@kernel.org, idosch@nvidia.com, willemb@google.com,
kuniyu@google.com, kees@kernel.org, richardbgobert@gmail.com,
alice.kernel@fastmail.im, gal@nvidia.com,
jibin.zhang@mediatek.com, luoxuanqiang@kylinos.cn,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Vega <vega@nebusec.ai>, Luxing Yin <root@tr0jan.top>
Subject: Re: [PATCH net v3 1/1] net: gso: limit recursive IP-in-IP segmentation
Date: Mon, 21 Sep 2026 21:23:22 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.102e0468a26de@gmail.com> (raw)
In-Reply-To: <43510074c063f57e5738ecc55057e7fbbcdb1fbc.1789802623.git.zihanx@nebusec.ai>
Zihan Xi wrote:
> IPIP GSO/TSO support makes IP-in-IP GSO dispatch re-enter
> inet_gso_segment() or ipv6_gso_segment() for every nested IP header. The
> only state that tracks this nesting is encap_level, which records header
> bytes and has no recursion bound. A sufficiently deep chain can consume the
> kernel stack before a transport GSO callback is reached.
>
> The unbounded callback nesting was introduced when inet_gso_segment() was
> made stackable by "ipv4: gso: make inet_gso_segment() stackable". GRE GSO
> support predated that change, and IP-in-IP GSO/TSO support later made the
> affected path reachable.
>
> The corresponding IPv6 stackable path was introduced separately by
> "ipv6: gso: make ipv6_gso_segment() stackable". This patch uses the same
> budget for IPv6, but the Fixes tag covers the IPv4 root cause only.
>
> Limit the cumulative header budget for a GSO operation to GSO_MAX_HEADER
> (256 bytes). Keep the consumed budget in skb_gso_cb and charge each header
> before dispatching the next GSO callback. The callback wrapper checks the
> same state, so direct IP handler re-entry and nested tunnel dispatch share
> one monotonic budget. GRE and UDP context resets cannot restart it before
> an inner GSO callback; other GSO tunnel and extension handlers charge their
> stripped headers before inner dispatch as well.
>
> GSO_MAX_HEADER is a practical header budget, not a measured stack-overflow
> threshold or an architecture-independent stack-safety proof. With a zero
> initial offset, 12 minimum-sized IPv4 headers consume 240 bytes; the next
> header is rejected. IPv6 base headers, extension headers, and tunnel
> headers use the budget faster. Validation of the preceding
> implementation on x86_64 used a 16 KiB task stack and completed without a
> stack-guard fault, but this does not establish a uniform margin for
> architectures with smaller stacks.
>
> Fixes: 3347c9602955 ("ipv4: gso: make inet_gso_segment() stackable")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Assisted-by: LLM
> Co-developed-by: Luxing Yin <root@tr0jan.top>
> Signed-off-by: Luxing Yin <root@tr0jan.top>
> Signed-off-by: Zihan Xi <zihanx@nebusec.ai>
>
> ---
> changes in v3:
> - Treat an exhausted 256-byte budget as a callback-entry failure, including
> the zero-length check used by the common callback wrapper and IP handlers.
> - v2 Link: https://lore.kernel.org/all/cover.1789618203.git.zihanx@nebusec.ai/
> changes in v2:
> - Replace the callback counter with a cumulative 256-byte header budget
> carried in skb_gso_cb.
> - Apply the budget at common callback entry and across IP, GRE, UDP, MPLS,
> NSH, ESP, and IPv6 extension dispatch, including GRE/UDP context resets.
> - Rebase the UDP hunk onto selected revision c9151088f167 and rerun both
> IPv4 PoCs; use the decoded crash evidence from unpatched 88c17de85ddb.
> - v1 Link: https://lore.kernel.org/all/cover.1789302084.git.zihanx@nebusec.ai/
> include/net/gso.h | 29 +++++++++++++++++++++++++++++
> net/core/gso.c | 7 +++++--
> net/ipv4/af_inet.c | 7 ++++++-
> net/ipv4/esp4_offload.c | 9 +++++++--
> net/ipv4/gre_offload.c | 2 ++
> net/ipv4/udp_offload.c | 4 +++-
> net/ipv6/esp6_offload.c | 9 +++++++--
> net/ipv6/ip6_offload.c | 11 ++++++++++-
> net/mpls/mpls_gso.c | 2 ++
> net/nsh/nsh.c | 2 ++
> 10 files changed, 73 insertions(+), 9 deletions(-)
This is a lot of code change compared to v1, a simple recursion
counter. Wang already suggested a simplication.
If the previous approach could be tested at only the two
network header callbacks, then this likely can too. By just bounding
skb_network_header - skb_mac_header? Or skb->data. Each pass through
these functions does an skb_pull.
prev parent reply other threads:[~2026-09-22 1:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 11:14 [PATCH net v3 0/1] net: gso: limit recursive IP-in-IP segmentation Zihan Xi
2026-09-19 11:14 ` [PATCH net v3 1/1] " Zihan Xi
2026-09-21 4:29 ` Wang Zhan
2026-09-22 1:23 ` Willem de Bruijn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willemdebruijn.kernel.102e0468a26de@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=alice.kernel@fastmail.im \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=jibin.zhang@mediatek.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luoxuanqiang@kylinos.cn \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardbgobert@gmail.com \
--cc=root@tr0jan.top \
--cc=stable@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=vega@nebusec.ai \
--cc=willemb@google.com \
--cc=zihanx@nebusec.ai \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.