Netdev List
 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 08/15] net: skbuff: make skb_try_coalesce()'s len unsigned
Date: Fri, 23 Oct 2026 04:52:06 +0000	[thread overview]
Message-ID: <179273112692.3134.1759491419702666549@kernel.org> (raw)
In-Reply-To: <20261019-b4-skbuff-bug-on-followups-v1-8-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 gets the bug's history wrong, so the single
  Fixes: tag (279877d86c82) is incomplete.

--

net: skbuff: make skb_try_coalesce()'s len unsigned

This changes the local len in skb_try_coalesce() from int to unsigned int,
so a from->len above INT_MAX can no longer pass the skb_tailroom() check.
It also adds an explicit delta < 0 test to the truesize WARN_ON_ONCE(),
since that comparison is now unsigned.

Link: https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@toxicpanda.com/

> Before that commit skb_put() ran first,
> and its overflow check caught such a length before anything was
> copied.

[Severity: Low]

Is this accurate on all configurations? Before 279877d86c82,
skb_try_coalesce() looked like this:

	if (len <= skb_tailroom(to) && skb_frags_readable(from)) {
		if (len)
			BUG_ON(skb_copy_bits(from, 0, skb_put(to, len), len));

len was already a signed int at that point. A from->len above INT_MAX
passed the tailroom check then, the same way it does now.

skb_put() then does:

	skb->tail += len;
	skb->len  += len;
	if (unlikely(skb->tail > skb->end))
		skb_over_panic(skb, len, __builtin_return_address(0));

On 32-bit, sk_buff_data_t is unsigned char *. A lowmem tail at or above
0x80000000 plus a len at or above 0x80000000 wraps below end, so
skb_over_panic() is never called. skb_put() returns the old tail, and
skb_copy_bits() runs with the negative len. That is the same large write
past @to that the commit message attributes to 279877d86c82.

On 64-bit, tail and end are u32 offsets. A from->len in the range
[2^32 - tail, 2^32) also wraps tail below end and gets past the check.
279877d86c82 seems to have widened this window on 64-bit, but it did not
open it.

git blame shows that the signed len goes back to the introduction of the
function:

  bad43ca8325f4 ("net: introduce skb_try_coalesce()")

Could the commit message be corrected? Should a Fixes: tag for
bad43ca8325f4 also be added? Without it, stable trees that don't contain
279877d86c82, including their 32-bit builds, may not get this fix.

> Fixes: 279877d86c82 ("net: skbuff: don't BUG() when skb_copy_bits() fails in copy helpers")

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

  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 [this message]
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
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=179273112692.3134.1759491419702666549@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox