All of lore.kernel.org
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: josef@toxicpanda.com
Cc: davem@davemloft.net, edumazet@kernel.org, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch,
	jgross@suse.com, sstabellini@kernel.org,
	willemdebruijn.kernel@gmail.com, fmancera@suse.de,
	almasrymina@google.com, david.laight.linux@gmail.com,
	netdev@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH net-next 11/15] net: skbuff: refuse to segment a nested frag_list
Date: Fri, 23 Oct 2026 04:52:11 +0000	[thread overview]
Message-ID: <179273113115.3134.9365887081510077540@kernel.org> (raw)
In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-11-41dbef50b9f7@toxicpanda.com>

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] The commit message for "net: skbuff: refuse to segment a nested
  frag_list" says "Nothing in the tree is known to build such an skb;…

--

net: skbuff: refuse to segment a nested frag_list

This adds a check to skb_segment() that rejects an skb whose frag_list
members have frag_lists of their own. It fails with -EINVAL and calls
DEBUG_NET_WARN_ON_ONCE(), since the segmentation walk would otherwise run
out of members and dereference a NULL list_skb.

> Nothing in the tree is known to build such an skb; GRO flushes instead
> of chaining an skb that already has a frag_list.  Check for it up front

[Severity: Low]

Is the first half of this sentence accurate as a general statement?

IP fragment reassembly appears to build exactly this layout. When the
first fragment already has a frag_list, inet_frag_reasm_prepare() moves
that frag_list under a new zero-length skb:

net/ipv4/inet_fragment.c:inet_frag_reasm_prepare() {
    ...
	if (skb_has_frag_list(head)) {
		struct sk_buff *clone;
		...
		clone = alloc_skb(0, GFP_ATOMIC);
		...
		skb_shinfo(clone)->frag_list = skb_shinfo(head)->frag_list;
		skb_frag_list_init(head);
		...
		skb_shinfo(head)->frag_list = clone;
		nextp = &clone->next;
    ...
}

The result is head -> frag_list[clone -> frag_list[...]]. That is the
nested layout the new check in skb_segment() rejects.

The GRO part is correct. dev_gro_receive() sets:

	NAPI_GRO_CB(skb)->flush = skb_has_frag_list(skb);

Reassembled skbs are not GSO, so they don't normally reach skb_segment().
The narrower claim seems to be what's meant: no in-tree path builds a GSO
skb with a nested frag_list.

Could the commit message say that instead, and mention IP defrag as a
known non-GSO source of nested frag_lists?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261019-b4-skbuff-bug-on-followups-v1-0-41dbef50b9f7%40toxicpanda.com


  parent reply	other threads:[~2026-10-23  4:52 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 13:50 [PATCH net-next 00/15] net: skbuff: follow-ups to the BUG_ON() removal Josef Bacik
2026-10-19 13:50 ` [PATCH net-next 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags Josef Bacik
2026-10-23  4:51   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 02/15] net: skbuff: add skb_checksum_full() that reports failure Josef Bacik
2026-10-23  4:51   ` netdev-bot+sashiko
2026-10-23 14:01   ` Mina Almasry
2026-10-19 13:50 ` [PATCH net-next 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed Josef Bacik
2026-10-23  4:51   ` netdev-bot+sashiko
2026-10-23 14:12     ` Mina Almasry
2026-10-23 14:37   ` Mina Almasry
2026-10-19 13:50 ` [PATCH net-next 04/15] net: skbuff: fail segmentation when a segment " Josef Bacik
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-23 14:14   ` Mina Almasry
2026-10-19 13:50 ` [PATCH net-next 05/15] net: skbuff: fail pskb_trim_rcsum() when it can't checksum the tail Josef Bacik
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 06/15] net: skbuff: add skb_crc32c_full() that reports failure Josef Bacik
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 07/15] net: skbuff: let skb_zerocopy() copy a short skb without head_frag Josef Bacik
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 08/15] net: skbuff: make skb_try_coalesce()'s len unsigned Josef Bacik
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 09/15] net: skbuff: check csum_start against len in skb_copy_and_csum_dev() Josef Bacik
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 10/15] net: skbuff: reject a negative length in skb_copy_and_csum_bits() Josef Bacik
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 11/15] net: skbuff: refuse to segment a nested frag_list Josef Bacik
2026-10-20 20:09   ` Willem de Bruijn
2026-10-23  4:52   ` netdev-bot+sashiko [this message]
2026-10-19 13:50 ` [PATCH net-next 12/15] net: test the frag_list layouts skb_segment() refuses Josef Bacik
2026-10-20 20:17   ` Willem de Bruijn
2026-10-19 13:50 ` [PATCH net-next 13/15] xen-netfront: don't BUG() when skb_copy_bits() fails in bounce_skb() Josef Bacik
2026-10-19 13:50 ` [PATCH net-next 14/15] net/tls: don't BUG() on leftover length in __skb_nsg() Josef Bacik
2026-10-19 15:12   ` Mina Almasry
2026-10-19 16:22     ` Willem de Bruijn
2026-10-19 16:27       ` Mina Almasry
2026-10-23  4:52   ` netdev-bot+sashiko
2026-10-19 13:50 ` [PATCH net-next 15/15] net: update comments that still describe the skb BUG_ON()s Josef Bacik
2026-10-19 15:09   ` Mina Almasry

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=179273113115.3134.9365887081510077540@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=almasrymina@google.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=david.laight.linux@gmail.com \
    --cc=edumazet@kernel.org \
    --cc=fmancera@suse.de \
    --cc=horms@kernel.org \
    --cc=jgross@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sstabellini@kernel.org \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.