Re: [PATCH net-next v3 01/15] net: skbuff: make skb_copy_and_csum_bits() report unreadable frags

[Mina Almasry <almasrymina@xxxxxxxxxx>]

On Mon, Nov 2, 2026 at 6:28 PM Josef Bacik <josef@xxxxxxxxxxxxxx> wrote:
>
> skb_copy_and_csum_bits() has no way to fail.  When it reaches unreadable
> frags, or runs out of skb before @len, it zero-fills the rest of the
> buffer and returns 0.  Its callers can't tell that the copy didn't
> happen.
>
> In the !sg && !csum branch of skb_segment() that turns a devmem TCP
> payload into zeroes under a valid TCP checksum, and the peer accepts
> them as stream data.  It takes a device with both SG and TX checksum
> offload turned off.  A test module that segments an skb with 3000 bytes
> in an unreadable frag gets 3 all-zero segments before this patch and
> -EFAULT after it.
>
> Return 0 or -EFAULT, hand the checksum back through a pointer, and mark
> the function __must_check.  Every caller takes the error path it already
> has for a failed copy.  skb_copy_and_csum_dev() can't return an error,
> so it zeroes the whole frame.  csum_partial_copy_to_xdr() no longer
> checksums the bytes it didn't copy.  That only ran when the function was
> about to fail anyway, and skb_checksum() warns on an unreadable skb.
>
> The frag_list loop takes the address of a local, so it moves into a
> noinline function to keep a stack protector out of
> skb_copy_and_csum_bits().
>
> Found by the Sashiko AI review of commit ab9414ed70bd ("net: skbuff:
> don't leave stale bytes in skb_copy_and_csum_bits()").
>
> Fixes: ab9414ed70bd ("net: skbuff: don't leave stale bytes in 
> skb_copy_and_csum_bits()")
> Fixes: 417261779eab ("net: skbuff: don't BUG() on leftover length in 
> skb_copy_and_csum_bits()")
> Fixes: 65249feb6b3d ("net: add support for skbs with unreadable frags")
> Link: 
> https://lore.kernel.org/all/179148235783.434549.14322374227477832817@xxxxxxxxxx/
> Suggested-by: Mina Almasry <almasrymina@xxxxxxxxxx>
> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>

Reviewed-by: Mina Almasry <almasrymina@xxxxxxxxxx>