[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH net-next 03/15] net: skbuff: fail checksum validation when the skb can't be checksummed


  • To: Josef Bacik <josef@xxxxxxxxxxxxxx>
  • From: Mina Almasry <almasrymina@xxxxxxxxxx>
  • Date: Fri, 23 Oct 2026 07:37:23 -0700
  • Arc-authentication-results: i=1; mx.google.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=TbyyQ/cVBjURwEkpwzvfBfCIIo+L2tVbdO6SgJnUJTQ=; fh=SW+8ZejeTBE2+9JuXfQboCoaPlVZgeA720cesd9C3AE=; b=Xz7nm5S94qyjf3r5XXyK8uCJhNLZS1k5rRgF5TtjG8Syamo8PkVAmBQKvkj9J7ucGI Hww1K8bE649duhf97M9TYgmgO0p2XwAkw8KOZp8CfxwX92FWyMTtmZ270fvPeKiC0zKr qovE1QCGvCi93rfbJPxywUf38d/T+KGjyb5pRFcl23mKb77xd5bcNS/QZvJuJk4tWR0I rkgmzponD1kSOLYfz95qvuNlcgJurQXqtSap9vZ5JfuYG3qXkKqzXDtPxf9q7GaolxMc pG/nxWoRMLW3cqjo26iO0T5zio+/PiauVjgcJ7xRIVzTciuar4dIdOGwV55ZiSzruvFs 5zxA==; darn=lists.xenproject.org
  • Arc-seal: i=1; a=rsa-sha256; t=1792766256; cv=none; d=google.com; s=arc-20260327; b=OfuFDZHYGvbNtbmpUaGLSHkKkWvAROh4hlZFivW9w+O/ZnYEq1DtgvrzlbRxxtmVlc oXmEAV4a2f47yEuwdPJQMYuHmGu5XYlf0Fi0DWTLYtllOzXW1NyOHgP5aCG79IMr2ZX+ jq3jJmabGErAhLbRWXkIwrReDpQegJOiDQ16Ezw4xo9JO3qWIu0mHGqqnGjTsU9LX2JK Xcc7bw5qmFS0jSarTXKgpimyxHKMa7/aqyPElI2pdDGZ6uzfxoh1xaol3i0mB6rZB10r RCgjZka+q3oCRIZXvRPMWcnL1+wCSQsDGQsFOWyfj56VW6Z14ZuOhG0esjYtSkM5JHDH ofdA==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=google.com header.i="@google.com" header.h="Content-Transfer-Encoding:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
  • Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, Eric Dumazet <edumazet@xxxxxxxxxx>, Jakub Kicinski <kuba@xxxxxxxxxx>, Paolo Abeni <pabeni@xxxxxxxxxx>, Simon Horman <horms@xxxxxxxxxx>, Andrew Lunn <andrew+netdev@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx>, Fernando Fernandez Mancera <fmancera@xxxxxxx>, David Laight <david.laight.linux@xxxxxxxxx>, netdev@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 23 Oct 2026 14:37:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Oct 19, 2026 at 6:51 AM Josef Bacik <josef@xxxxxxxxxxxxxx> wrote:
>
> __skb_checksum_complete() verifies a received packet with
> skb_checksum(), which returns 0 when the range runs into unreadable
> frags or past the end of the skb.  0 is a valid sum, so it's treated as
> one: it adds skb->csum, the pseudo-header sum, and folds the result.
> With a sum of 0 that's csum_fold(skb->csum), which is 0 whenever the
> pseudo-header sum folds to 0xffff, so a packet whose payload was never
> checksummed is accepted, marked csum_valid, and left with a wrong
> CHECKSUM_COMPLETE value in skb->csum.
>
> __skb_checksum_complete_head() passes skb->csum in as the seed, so a
> failure there folds 0 and the packet fails validation, but only because
> skb_checksum() happened to drop the seed.
>
> Use skb_checksum_full() in both, and report a packet that can't be
> checksummed as having a bad checksum, so callers drop it the way they
> drop any other bad checksum.  Clear csum_valid, and leave skb->csum and
> ip_summed alone, since there's no full packet checksum to store.
>
> Found by the Sashiko AI review of the series that made skb_checksum()
> return 0 for a range past the end of the skb.
>
> Fixes: 20ddd0fd2fcd ("net: skbuff: don't BUG() on leftover length in 
> skb_checksum() and friends")
> Link: 
> https://lore.kernel.org/all/20261007-b4-skbuff-bug-on-v2-0-b9a5f732895b@xxxxxxxxxxxxxx/
> Assisted-by: LLM
> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> ---
>  net/core/skbuff.c | 21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 061c61422a38..40d2dd20d47d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3860,9 +3860,17 @@ EXPORT_SYMBOL(skb_crc32c);
>
>  __sum16 __skb_checksum_complete_head(struct sk_buff *skb, int len)
>  {
> +       __wsum csum = skb->csum;
>         __sum16 sum;
>
> -       sum = csum_fold(skb_checksum(skb, 0, len, skb->csum));
> +       /* If the data can't be checksummed it can't be valid either. */
> +       if (skb_checksum_full(skb, 0, len, &csum)) {
> +               if (!skb_shared(skb))
> +                       skb->csum_valid = 0;
> +               return (__force __sum16)1;
> +       }
> +
> +       sum = csum_fold(csum);
>         /* See comments in __skb_checksum_complete(). */
>         if (likely(!sum)) {
>                 if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE) &&
> @@ -3886,10 +3894,17 @@ EXPORT_SYMBOL(__skb_checksum_complete_head);
>   */
>  __sum16 __skb_checksum_complete(struct sk_buff *skb)
>  {
> -       __wsum csum;
> +       __wsum csum = 0;
>         __sum16 sum;
>
> -       csum = skb_checksum(skb, 0, skb->len, 0);
> +       /* If the data can't be checksummed it can't be valid either.  Leave
> +        * skb->csum alone, it's not a full packet checksum.
> +        */
> +       if (skb_checksum_full(skb, 0, skb->len, &csum)) {
> +               if (!skb_shared(skb))
> +                       skb->csum_valid = 0;
> +               return (__force __sum16)1;
> +       }

I think maybe we need to be careful here which are all the skb flags
that we need to touch to indicate that the checksum failed.

My LLM is recommending:

        if (!skb_shared(skb)) {
            skb->ip_summed = CHECKSUM_NONE;
            skb->csum_complete_sw = 0;
            skb->csum_valid = 0;
        }

Seems ip_summed = *_NONE was caught elsewhere, but also maybe
csum_complete_sw=0 makes sense.

-- 
Thanks,
Mina



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.