All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Josef Bacik <josef@toxicpanda.com>,
	 "David S. Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@kernel.org>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	 Simon Horman <horms@kernel.org>,
	 Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Juergen Gross <jgross@suse.com>,
	 Stefano Stabellini <sstabellini@kernel.org>,
	 Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	 Fernando Fernandez Mancera <fmancera@suse.de>,
	 Mina Almasry <almasrymina@google.com>,
	 David Laight <david.laight.linux@gmail.com>,
	 netdev@vger.kernel.org,  xen-devel@lists.xenproject.org,
	 Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH net-next 11/15] net: skbuff: refuse to segment a nested frag_list
Date: Tue, 20 Oct 2026 16:09:37 -0400	[thread overview]
Message-ID: <willemdebruijn.kernel.29f6b224b2d77@gmail.com> (raw)
In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-11-41dbef50b9f7@toxicpanda.com>

Josef Bacik wrote:
> skb_segment() walks head_skb's frag_list, but for each member it only
> looks at the linear part and frags[], never at the member's own
> frag_list.  head_skb->len still counts those bytes, so with a nested
> frag_list the walk runs out of members while it still owes data, sets
> list_skb to NULL, and dereferences it on the next pass, before any of
> the layout checks get a chance to catch it.
> 
> 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
> and fail the segmentation with -EINVAL, with a DEBUG_NET_WARN_ON_ONCE()
> for debug kernels, like the other frag_list layout checks.
> 
> Assisted-by: LLM
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
>  net/core/skbuff.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 56cec58bccb7..b6ada54ecc57 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -4962,6 +4962,17 @@ struct sk_buff *skb_segment_list(struct sk_buff *skb,
>  }
>  EXPORT_SYMBOL_GPL(skb_segment_list);
>  
> +/* skb_segment() only walks one level of frag_list. */
> +static bool skb_segment_nested_frag_list(const struct sk_buff *head_skb)
> +{
> +	const struct sk_buff *iter;
> +
> +	skb_walk_frags(head_skb, iter)
> +		if (skb_has_frag_list(iter))
> +			return true;

We can probably check the same without adding an extra skb_walk_frags.

Perhaps

@@ -5025,6 +5025,12 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
 
                while (pos < offset + len) {
                        if (i >= nfrags) {
+                               if (unlikely(!list_skb || skb_has_frag_list(list_skb))) {
+                                       DEBUG_NET_WARN_ON_ONCE(1);
+                                       err = -EINVAL;
+                                       goto err;
+                               }
+

> +	return false;
> +}
> +
>  /**
>   *	skb_segment - Perform protocol segmentation on skb.
>   *	@head_skb: buffer to segment
> @@ -5023,6 +5034,16 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
>  	sg = !!(features & NETIF_F_SG);
>  	csum = !!can_checksum_protocol(features, proto);
>  
> +	/* The walk below never looks inside a member's own frag_list, but
> +	 * head_skb->len counts those bytes, so it would run out of members
> +	 * and dereference a NULL list_skb.
> +	 */
> +	if (unlikely(list_skb && skb_segment_nested_frag_list(head_skb))) {
> +		DEBUG_NET_WARN_ON_ONCE(1);
> +		err = -EINVAL;
> +		goto err;
> +	}
> +
>  	if (sg && csum && !gso_by_frags)  {
>  		if (!max_segs && !(features & NETIF_F_GSO_PARTIAL)) {
>  			struct sk_buff *iter;
> 
> -- 
> 2.55.0
> 



  reply	other threads:[~2026-10-20 20:09 UTC|newest]

Thread overview: 22+ 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-19 13:50 ` [PATCH net-next 02/15] net: skbuff: add skb_checksum_full() that reports failure Josef Bacik
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-19 13:50 ` [PATCH net-next 04/15] net: skbuff: fail segmentation when a segment " Josef Bacik
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-19 13:50 ` [PATCH net-next 06/15] net: skbuff: add skb_crc32c_full() that reports failure Josef Bacik
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-19 13:50 ` [PATCH net-next 08/15] net: skbuff: make skb_try_coalesce()'s len unsigned Josef Bacik
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-19 13:50 ` [PATCH net-next 10/15] net: skbuff: reject a negative length in skb_copy_and_csum_bits() Josef Bacik
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 [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-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=willemdebruijn.kernel.29f6b224b2d77@gmail.com \
    --to=willemdebruijn.kernel@gmail.com \
    --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=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.