[PATCH] net: gro: don't chain linear parts larger than gso_size into frag_list

[PATCH] net: gro: don't chain linear parts larger than gso_size into frag_list

[Sorah Fukumori]

skb_gro_receive() chains an skb into the frag_list of the held packet
when its payload cannot be attached as page frags, i.e. when its head
is not a page fragment and still holds payload. Since commit
5eddb24901ee ("gro: add support of (hw)gro packets to gro stack"), that
skb may itself be a GSO packet whose linear part holds several
gso_size segments. skb_segment() cannot split the linear part of a
frag_list member across segments, so segmenting the aggregate in
software, e.g. when forwarding it to a device without NETIF_F_FRAGLIST,
hits

  BUG_ON(skb_headlen(list_skb) > len);

Fully linear GSO packets come from generic XDP. When the program does
not support frags, netif_skb_check_for_xdp() linearizes any nonlinear
skb with pskb_expand_head() and skb_linearize() and keeps its GSO
metadata. GRO on the device runs before generic XDP, so each aggregate
passed by the program carries all of its payload in a kmalloc'ed head.
A tunnel that decapsulates these packets and runs GRO again through
gro_cells then builds the bad frag_list. This was first seen on a
router that forwards TCP received over VXLAN, with a non-frags XDP
program attached in SKB mode to the underlying bond because one slave
lacks native XDP:

  kernel BUG at net/core/skbuff.c:4917!
  RIP: 0010:skb_segment+0xbb6/0xf40
  Call Trace:
   tcp_gso_segment
   ipv6_gso_segment
   skb_mac_gso_segment
   __skb_gso_segment
   validate_xmit_skb
   __dev_queue_xmit
   ip6_output
   ip6_sublist_rcv_finish
   ipv6_list_rcv
   netif_receive_skb_list_internal
   gro_complete
   dev_gro_receive
   gro_receive_skb
   gro_cell_poll
   __napi_poll
   net_rx_action

It reproduces with three network namespaces: TCP sent over VXLAN on an
IPv6 veth link to a router namespace that has an XDP_PASS program
without frags support attached to the underlay veth in generic mode
and GRO enabled on its VXLAN device, and forwards to a veth with
tx-scatter-gather-fraglist disabled.

Refuse the merge when the linear part to be chained exceeds the held
packet's gso_size. tcp_gro_receive() then flushes the held packet and
the skb starts a new GRO packet as its head, whose linear length
skb_segment() handles.

Fixes: 5eddb24901ee ("gro: add support of (hw)gro packets to gro stack")
Cc: stable@vger.kernel.org
Assisted-by: claude-opus-5-5
Signed-off-by: Sorah Fukumori <her@sorah.jp>
---
 net/core/gro.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/net/core/gro.c b/net/core/gro.c
index 29b4d02bf519..ff828a3dce3c 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -187,6 +187,10 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)
 	}
 
 merge:
+	/* skb_segment() cannot split the linear part of a frag_list member. */
+	if (unlikely(headlen > offset + skb_shinfo(p)->gso_size))
+		return -E2BIG;
+
 	/* sk ownership - if any - completely transferred to the aggregated packet */
 	skb->destructor = NULL;
 	skb->sk = NULL;
-- 
2.55.0

Re: [PATCH] net: gro: don't chain linear parts larger than gso_size into frag_list

[Eric Dumazet]

Le mar. 13 oct. 2026 à 12:25, Sorah Fukumori <her@sorah.jp> a écrit :
>
> skb_gro_receive() chains an skb into the frag_list of the held packet
> when its payload cannot be attached as page frags, i.e. when its head
> is not a page fragment and still holds payload.

>
> Fully linear GSO packets come from generic XDP. When the program does
> not support frags, netif_skb_check_for_xdp() linearizes any nonlinear
> skb with pskb_expand_head() and skb_linearize() and keeps its GSO
> metadata.

On Tue, Oct 13, 2026 at 12:24 PM Sorah Fukumori <her@sorah.jp> wrote:
>
> skb_gro_receive() chains an skb into the frag_list of the held packet
> when its payload cannot be attached as page frags, i.e. when its head
> is not a page fragment and still holds payload.

[...]

> Fully linear GSO packets come from generic XDP. When the program does
> not support frags, netif_skb_check_for_xdp() linearizes any nonlinear
> skb with pskb_expand_head() and skb_linearize() and keeps its GSO
> metadata.

I think the problem is a bit wider than what is described here.

skb_gro_receive() also reaches the merge: label from the head_frag
branch, when the frags do not fit:

if (nr_frags + 1 + skbinfo->nr_frags > MAX_SKB_FRAGS)
goto merge;

A GSO skb with a page frag head holding more than gso_size bytes of
payload is then chained in frag_list as well, and the BUG_ON() in
skb_segment() does not care about head_frag.

It seems an XDP program with frags support in generic mode could
get there: skb_pp_cow_data() builds a head_frag skb with up to
about one page of linear data, the rest in page frags, and
skb_copy_header() keeps the GSO metadata. Two such 64KB packets
can not share a single frags[] array.

Have you tried this variant with your reproducer ?

Your patch handles it anyway, since the check is done at the merge:
label, but the changelog should mention it.

>
> Fixes: 5eddb24901ee ("gro: add support of (hw)gro packets to gro stack")
> Cc: stable@vger.kernel.org
> Assisted-by: claude-opus-5-5
> Signed-off-by: Sorah Fukumori <her@sorah.jp>
> ---
>  net/core/gro.c | 4 ++++
>  1 file changed, 4 insertions(+)

Please use [PATCH net] in the subject for fixes.

The fix itself looks good to me, thanks.

Reviewed-by: Eric Dumazet <edumazet@kernel.org>

Re: [PATCH] net: gro: don't chain linear parts larger than gso_size into frag_list

[Sorah Fukumori]

Hi,

On Tue, 13 Oct 2026, at 8:03 PM, Eric Dumazet wrote:
> It seems an XDP program with frags support in generic mode could
> get there: skb_pp_cow_data() builds a head_frag skb with up to
> about one page of linear data, the rest in page frags, and
> skb_copy_header() keeps the GSO metadata. Two such 64KB packets
> can not share a single frags[] array.
>
> Have you tried this variant with your reproducer ?

Thanks, I haven't. I tried to reproduce that variant under various gro_max_size/RPS configuration, but I couldn't repro on my qemu+veth based script.

Will send out v2 with updated commit message soon, and sorry about missing `net` prefix in the subject, it will be included in v2.