From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Zihan Xi <zihanx@nebusec.ai>,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, dsahern@kernel.org, idosch@nvidia.com
Cc: zihanx@nebusec.ai, horms@kernel.org, kees@kernel.org,
willemb@google.com, kuniyu@google.com,
richardbgobert@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v5 1/1] net: gso: limit recursive IP-in-IP segmentation
Date: Wed, 23 Sep 2026 11:26:53 -0400 [thread overview]
Message-ID: <willemdebruijn.kernel.36edefe3b0b17@gmail.com> (raw)
In-Reply-To: <8b7e7dad82a40e7bdb4721516823c8a7ae6106a0.1790161599.git.zihanx@nebusec.ai>
Zihan Xi wrote:
> IP-in-IP GSO can re-enter inet_gso_segment() or ipv6_gso_segment()
> for each nested IP header. encap_level tracks header bytes, not callback
> depth, so a deep chain can exhaust the kernel stack. Making
> inet_gso_segment() stackable introduced unbounded IPv4 nesting; IPIP
> GSO/TSO later made the path reachable. The IPv6 stackable path was
> introduced separately and shares the guard; Fixes identifies the IPv4
> root cause.
>
> Count IPv4 and IPv6 GSO handler entries in skb_gso_cb, initialized once
> per top-level GSO operation and preserved across GRE/UDP context changes.
> Set the cap to five, matching IP_TUNNEL_RECURSION_LIMIT. Allow five
> entries and reject the sixth with -EINVAL before it can dispatch another
> GSO callback.
>
> On the patched x86_64 kernel, tracefs observed six
> inet_gso_segment() entries for the 199-header reproducer; the sixth
> returned -EINVAL without a stack-guard fault. This validates the tested
> configuration, not an architecture-independent stack-safety margin.
>
> 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 v5:
> - Replace the header-offset budget with a shared IP GSO handler-entry
> counter. Entries one through five pass; entry six is rejected.
> - Initialize the count for each top-level GSO operation and preserve it
> across IPv4/IPv6 dispatch and GRE/UDP context changes.
> - Use the existing IP_TUNNEL_RECURSION_LIMIT value of five as a
> practical bound. Tracefs observed the sixth entry return -EINVAL on
> the final x86_64 revision; rerun both IPv4 PoCs on that revision.
> - Avoid rejecting a single-level tunnel based only on header length.
> - v4 Link: https://lore.kernel.org/all/cover.1790041241.git.zihanx@nebusec.ai/
> include/net/gso.h | 9 +++++++++
> net/core/gso.c | 1 +
> net/ipv4/af_inet.c | 2 ++
> net/ipv6/ip6_offload.c | 2 ++
> 4 files changed, 14 insertions(+)
>
> diff --git a/include/net/gso.h b/include/net/gso.h
> index 29975440c..18944ff06 100644
> --- a/include/net/gso.h
> +++ b/include/net/gso.h
> @@ -19,10 +19,19 @@ struct skb_gso_cb {
> int encap_level;
> __wsum csum;
> __u16 csum_start;
> + /* Number of IPv4/IPv6 GSO handler entries for this packet. */
> + u8 recursion_counter;
> };
> #define SKB_GSO_CB_OFFSET 32
> #define SKB_GSO_CB(skb) ((struct skb_gso_cb *)((skb)->cb + SKB_GSO_CB_OFFSET))
>
> +#define GSO_RECURSION_LIMIT 5
The commit-msg explains this as derived from IP_TUNNEL_RECURSION_LIMIT.
Which makes sense as a choice. Use that directly, rather than
duplicating it?
Or else at least add a comment. Right now it looks like an unexplained
magic variable.
If respinning, no need to send the long cover letter again, imho.
Reported-by: is expected to be followed by a Closes: tag. That can
point to the v5 cover letter on lore.kernel.org.
prev parent reply other threads:[~2026-09-23 15:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 14:01 [PATCH net v5 0/1] net: gso: limit recursive IP-in-IP segmentation Zihan Xi
2026-09-23 14:01 ` [PATCH net v5 1/1] " Zihan Xi
2026-09-23 15:26 ` 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.36edefe3b0b17@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardbgobert@gmail.com \
--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.