All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@kernel.org>
To: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: "Simon Horman" <horms@kernel.org>,
	"David Ahern" <dsahern@kernel.org>,
	"Ido Schimmel" <idosch@nvidia.com>,
	"Willem de Bruijn" <willemdebruijn.kernel@gmail.com>,
	"Marcelo Ricardo Leitner" <marcelo.leitner@gmail.com>,
	"Xin Long" <lucien.xin@gmail.com>,
	"Aaron Conole" <aconole@redhat.com>,
	"Eelco Chaudron" <echaudro@redhat.com>,
	"Ilya Maximets" <i.maximets@ovn.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Justin Iurman" <justin.iurman@gmail.com>,
	"Linus Lüssing" <linus.luessing@c0d3.blue>,
	"Sabrina Dubroca" <sd@queasysnail.net>,
	"Stefano Brivio" <sbrivio@redhat.com>,
	"Hyunwoo Kim" <imv4bel@gmail.com>,
	netdev@vger.kernel.org, linux-sctp@vger.kernel.org,
	dev@openvswitch.org, "Eric Dumazet" <edumazet@kernel.org>,
	stable@vger.kernel.org
Subject: [PATCH net 1/5] ipv6: gro: limit the number of extension headers
Date: Fri, 13 Nov 2026 13:46:21 +0100	[thread overview]
Message-ID: <20261113124625.4010206-2-edumazet@kernel.org> (raw)
In-Reply-To: <20261113124625.4010206-1-edumazet@kernel.org>

Hyunwoo Kim reported that a long chain of IPv6 extension headers
can push the transport header offset of a GRO packet beyond what
the 16-bit skb->transport_header can store. The truncated offset
is later used by gro_receive_network_flush() to locate the network
header of a packet held in the GRO list, leading to an out-of-bounds
read.

Since commit 3744b0964d52 ("ipv6: Implement limits on extension header
parsing"), ip6_protocol_deliver_rcu() drops packets carrying more than
IP6_MAX_EXT_HDRS_CNT extension headers, but ipv6_gro_pull_exthdrs()
was left unbounded.

There is no point trying to aggregate packets that the stack is going
to drop anyway if they are locally delivered. Apply the same limit in
ipv6_gro_pull_exthdrs().

When the limit is hit, @proto still designates an extension header.
Extension header offloads have no gro_receive() callback, so
ipv6_gro_receive() takes its existing "goto out" path with flush set,
and the packet is given to the normal receive path. Local delivery
drops it with SKB_DROP_REASON_IPV6_TOO_MANY_EXTHDRS, while forwarded
packets are simply not aggregated.

An extension header being at most 2048 bytes, this bounds a chain
to 24576 bytes.

Note that offsets can still accumulate over nested encapsulations,
so the places storing them should be hardened separately.

Fixes: 4b0ebbca3e16 ("net: gro: move L3 flush checks to tcp_gro_receive and udp_gro_receive_segment")
Cc: stable@vger.kernel.org
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Link: https://lore.kernel.org/netdev/avTTQNyvwPP6LtGx@v4bel/
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Ido Schimmel <idosch@nvidia.com>
---
 net/ipv6/ip6_offload.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 700f1861d8eb..01642900c0fa 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -26,6 +26,7 @@ static int ipv6_gro_pull_exthdrs(struct sk_buff *skb, int off, int proto)
 {
 	const struct net_offload *ops = NULL;
 	struct ipv6_opt_hdr *opth;
+	int exthdr_cnt = 0;
 
 	for (;;) {
 		int len;
@@ -38,6 +39,13 @@ static int ipv6_gro_pull_exthdrs(struct sk_buff *skb, int off, int proto)
 		if (!(ops->flags & INET6_PROTO_GSO_EXTHDR))
 			break;
 
+		/* Same limit as ip6_protocol_deliver_rcu().
+		 * @proto is left pointing to an extension header,
+		 * so that the caller does not aggregate this packet.
+		 */
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			break;
+
 		opth = skb_gro_header(skb, off + sizeof(*opth), off);
 		if (unlikely(!opth))
 			break;
-- 
2.53.0


  reply	other threads:[~2026-11-13 12:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 12:46 [PATCH net 0/5] net: avoid truncated transport header offsets Eric Dumazet
2026-11-13 12:46 ` Eric Dumazet [this message]
2026-11-13 12:58   ` [PATCH net 1/5] ipv6: gro: limit the number of extension headers Hyunwoo Kim
2026-11-13 12:46 ` [PATCH net 2/5] ipv6: mcast: use skb_set_transport_header_careful() in ipv6_mc_check_exthdrs() Eric Dumazet
2026-11-13 12:46 ` [PATCH net 3/5] net: openvswitch: use skb_set_transport_header_careful() in parse_ipv6hdr() Eric Dumazet
2026-11-13 12:46 ` [PATCH net 4/5] sctp: use skb_set_transport_header_careful() in sctp_v6_err() Eric Dumazet
2026-11-13 12:46 ` [PATCH net 5/5] udp: use skb_set_transport_header_careful() in __udp6_lib_err_encap() Eric Dumazet

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=20261113124625.4010206-2-edumazet@kernel.org \
    --to=edumazet@kernel.org \
    --cc=aconole@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=dsahern@kernel.org \
    --cc=echaudro@redhat.com \
    --cc=horms@kernel.org \
    --cc=i.maximets@ovn.org \
    --cc=idosch@nvidia.com \
    --cc=imv4bel@gmail.com \
    --cc=justin.iurman@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linus.luessing@c0d3.blue \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sbrivio@redhat.com \
    --cc=sd@queasysnail.net \
    --cc=stable@vger.kernel.org \
    --cc=willemdebruijn.kernel@gmail.com \
    /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.