All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Josef Bacik" <josef@toxicpanda.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net-next v2 6/8] net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()
Date: Thu, 08 Oct 2026 17:36:41 +0000	[thread overview]
Message-ID: <sashiko-outbox-164421@kernel.org> (raw)
In-Reply-To: <20261007-b4-skbuff-bug-on-v2-6-b9a5f732895b@toxicpanda.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] skb: negative len from broken caller causes OOB write before memset guard
--

commit b6b3af33d3ca9b0598654f13d4f01d9b22cff285
Author: Josef Bacik <josef@toxicpanda.com>

net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits()

This commit removes a BUG_ON(len) check and instead returns 0 after zeroing
any unfilled buffer space. It explicitly aims to avoid a massive memset if
a broken caller passes a negative length.

> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index c896770203f71..7fd2f8142cc41 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3713,7 +3713,13 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset,
>  		}
>  		start = end;
>  	}
> -	BUG_ON(len);
> +	if (unlikely(len)) {

[Severity: Medium]
Will this check ever be reached if a caller passes a negative len?

The commit message mentions avoiding a huge memset if len is negative,
but if len is negative, earlier loops in skb_copy_and_csum_bits() will
clamp their copy size to this negative value:

net/core/skbuff.c:skb_copy_and_csum_bits() {
    ...
    if (copy > 0) {
        if (copy > len)
            copy = len;
        csum = csum_partial_copy_nocheck(skb->data + offset, to, copy);
    ...
}

This negative copy value causes csum_partial_copy_nocheck() to perform a
massive out-of-bounds access.

Similarly, in the fragment loop, a negative len makes copy negative,
leading to an infinite loop and out-of-bounds writes in
skb_frag_foreach_page() due to unsigned comparisons.

Does this function need an early return for negative lengths at the entry
point to truly protect against broken callers?

> +		DEBUG_NET_WARN_ON_ONCE(1);
> +		/* Don't hand the caller a buffer with stale bytes in it. */
> +		if (len > 0)
> +			memset(to, 0, len);
> +		return 0;
> +	}
>  	return csum;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com?part=6

  reply	other threads:[~2026-10-08 17:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 17:35 [PATCH net-next v2 0/8] net: skbuff: replace most BUG_ON()s with error returns Josef Bacik
2026-10-07 17:36 ` [PATCH net-next v2 1/8] net: skbuff: don't BUG() on bad arguments to pskb_expand_head() Josef Bacik
2026-10-07 17:36 ` [PATCH net-next v2 2/8] net: skbuff: don't BUG() on a bad frag_list layout in skb_segment() Josef Bacik
2026-10-11 17:00   ` netdev-bot+sashiko
2026-10-07 17:36 ` [PATCH net-next v2 3/8] net: skbuff: don't BUG() when skb_copy_bits() fails in copy helpers Josef Bacik
2026-10-11 17:00   ` netdev-bot+sashiko
2026-10-07 17:36 ` [PATCH net-next v2 4/8] net: skbuff: don't BUG() on leftover length in skb_checksum() and friends Josef Bacik
2026-10-08 17:36   ` sashiko-bot
2026-10-11 17:00   ` netdev-bot+sashiko
2026-10-07 17:36 ` [PATCH net-next v2 5/8] net: skbuff: don't BUG() on a bad csum_start in skb_copy_and_csum_dev() Josef Bacik
2026-10-11 17:00   ` netdev-bot+sashiko
2026-10-07 17:36 ` [PATCH net-next v2 6/8] net: skbuff: don't BUG() on leftover length in skb_copy_and_csum_bits() Josef Bacik
2026-10-08 17:36   ` sashiko-bot [this message]
2026-10-11 17:00   ` netdev-bot+sashiko
2026-10-07 17:36 ` [PATCH net-next v2 7/8] net: skbuff: don't BUG() on a missing head_frag in skb_zerocopy() Josef Bacik
2026-10-11 17:00   ` netdev-bot+sashiko
2026-10-07 17:36 ` [PATCH net-next v2 8/8] net: skbuff: remove the BUG_ON()s from skb_shift() Josef Bacik

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=sashiko-outbox-164421@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.