From: Ting-Han Hou <ue081723@gmail.com>
To: stable@vger.kernel.org
Cc: Zihan Xi <zihanx@nebusec.ai>, Vega <vega@nebusec.ai>,
Luxing Yin <root@tr0jan.top>,
Willem de Bruijn <willemb@google.com>,
Paolo Abeni <pabeni@redhat.com>
Subject: [PATCH 6.1.y] net: gso: limit recursive IP-in-IP segmentation
Date: Sat, 24 Oct 2026 20:27:20 +0800 [thread overview]
Message-ID: <20261024122720.641-1-ue081723@gmail.com> (raw)
In-Reply-To: <2026100307-cost-creamed-3c21@gregkh>
From: Zihan Xi <zihanx@nebusec.ai>
[ Upstream commit 006c8b834aed8b02bd8fb9fb05e9e7ead37d1763 ]
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 uses the same guard.
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.
Use the existing IP_TUNNEL_RECURSION_LIMIT for both handlers. The first
five entries pass, and the sixth returns -EINVAL before dispatching
another GSO callback.
Fixes: 3347c9602955 ("ipv4: gso: make inet_gso_segment() stackable")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Closes: https://lore.kernel.org/all/cover.1790157745.git.zihanx@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>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260924051521.32568-2-zihanx@nebusec.ai
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
[ Ting-Han: this tree predates include/net/gso.h and net/core/gso.c, so
the skb_gso_cb change and gso_recursion_inc_test() go into
include/linux/skbuff.h and the reset into __skb_gso_segment() in
net/core/dev.c. IP_TUNNEL_RECURSION_LIMIT comes from the 6.1.y
backport of 6f1a9140ecda ("net: add xmit recursion limit to tunnel
xmit functions") and is still 4 because 77facb35227c ("net: increase
IP_TUNNEL_RECURSION_LIMIT to 5") is not here, so the fifth entry is
the one that fails until that commit is applied ]
Signed-off-by: Ting-Han Hou <ue081723@gmail.com>
---
Tested on top of v6.1.190 plus the whole current 6.1 queue
(stable-queue fa04d3db75, applied with quilt). It needs the queued
backport of 6f1a9140ecda ("net: add xmit recursion limit to tunnel
xmit functions") for IP_TUNNEL_RECURSION_LIMIT, which v6.1.190 and
6.1.191-rc1 do not have yet.
x86_64 defconfig + kvm_guest.config with KASAN, PROVE_LOCKING,
DEBUG_ATOMIC_SLEEP, DEBUG_LIST and UBSAN, built with and without the
patch and booted in QEMU/KVM. The guest sends 32 MiB of TCP over a
veth pair, over one ipip tunnel, over one ip6ip6 tunnel and over ipip
in ipip, with tx-ipxip4/6-segmentation turned off on the veth pair so
that the tunnel GSO packets are segmented in software. With and
without the patch all data arrives intact, there are no drops or
kernel warnings, and kprobes show two inet_gso_segment() or
ipv6_gso_segment() calls per __skb_gso_segment() call in the tunnel
cases, so these packets reach a count of 2 in the new check. No new
W=1 or sparse warnings in the changed .c files.
Not tested: the deep nesting reproducer from the upstream report, so
the -EINVAL path itself was not exercised.
77facb35227c ("net: increase IP_TUNNEL_RECURSION_LIMIT to 5") was
requested for 6.6.y and 6.1.y in
https://lore.kernel.org/stable/20261024093010.485-1-ue081723@gmail.com/
This patch does not depend on it.
Tool use: this backport was prepared with an LLM coding assistant
(Claude Code with Claude Opus 5.5), asked to backport 006c8b834aed to
the stable trees it failed to apply to and to test it. It resolved
the conflicts, wrote the note in the changelog and this text, wrote
the test scripts and the guest init, and ran the builds and QEMU tests
above. I reviewed the patch and the test results before sending.
include/linux/skbuff.h | 8 ++++++++
net/core/dev.c | 1 +
net/ipv4/af_inet.c | 3 +++
net/ipv6/ip6_offload.c | 4 ++++
4 files changed, 16 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 1f646364926e4..39bd362d405ff 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4960,10 +4960,18 @@ 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))
+static inline bool gso_recursion_inc_test(struct sk_buff *skb,
+ unsigned int limit)
+{
+ return ++SKB_GSO_CB(skb)->recursion_counter > limit;
+}
+
static inline int skb_tnl_header_len(const struct sk_buff *inner_skb)
{
return (skb_mac_header(inner_skb) - inner_skb->head) -
diff --git a/net/core/dev.c b/net/core/dev.c
index 7c0d0905dd31b..8f3355f509333 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3490,6 +3490,7 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
SKB_GSO_CB(skb)->mac_offset = skb_headroom(skb);
SKB_GSO_CB(skb)->encap_level = 0;
+ SKB_GSO_CB(skb)->recursion_counter = 0;
skb_reset_mac_header(skb);
skb_reset_mac_len(skb);
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index a09b90552cf6e..09719f0c5556d 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1390,6 +1390,9 @@ struct sk_buff *inet_gso_segment(struct sk_buff *skb,
int id;
skb_reset_network_header(skb);
+ if (unlikely(gso_recursion_inc_test(skb,
+ IP_TUNNEL_RECURSION_LIMIT)))
+ goto out;
nhoff = skb_network_header(skb) - skb_mac_header(skb);
if (unlikely(!pskb_may_pull(skb, sizeof(*iph))))
goto out;
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 171a5c1afefea..4907f4ebf2b3d 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -16,6 +16,7 @@
#include <net/tcp.h>
#include <net/udp.h>
#include <net/gro.h>
+#include <net/ip_tunnels.h>
#include "ip6_offload.h"
@@ -87,6 +88,9 @@ static struct sk_buff *ipv6_gso_segment(struct sk_buff *skb,
bool gso_partial;
skb_reset_network_header(skb);
+ if (unlikely(gso_recursion_inc_test(skb,
+ IP_TUNNEL_RECURSION_LIMIT)))
+ goto out;
nexthdr = ipv6_has_hopopt_jumbo(skb);
if (nexthdr) {
const int hophdr_len = sizeof(struct hop_jumbo_hdr);
--
2.53.0
next prev parent reply other threads:[~2026-10-24 12:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-03 13:17 FAILED: patch "[PATCH] net: gso: limit recursive IP-in-IP segmentation" failed to apply to 6.1-stable tree gregkh
2026-10-24 12:27 ` Ting-Han Hou [this message]
2026-10-24 20:11 ` [PATCH 6.1.y] net: gso: limit recursive IP-in-IP segmentation Sasha Levin
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=20261024122720.641-1-ue081723@gmail.com \
--to=ue081723@gmail.com \
--cc=pabeni@redhat.com \
--cc=root@tr0jan.top \
--cc=stable@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox