netdev - Re: [PATCH v3] net: Do not include padding in TCP GRO checksum

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 16 Nov 2013 09:53:01 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
	herbert@...dor.apana.org
Subject: Re: [PATCH v3] net: Do not include padding in TCP GRO checksum

On Sat, Nov 16, 2013 at 08:47:38AM +0800, Herbert Xu wrote:
> On Fri, Nov 15, 2013 at 03:00:34PM -0800, Alexander Duyck wrote:
> > In some recent tests I found the TCP checksum was being treated as valid
> > for certain frames with padding on them.  On closer inspection I found the
> > issue was that GRO was using the skb->len instead of the length recorded in
> > the IP/IPv6 header to determine the number of bytes to checksum.  As such
> > padded frames that actually had invalid checksums generated by adding the
> > padding to the checksum were being incorrectly tagged as valid.
> > 
> > This change corrects that by using the tot_len from IPv4 headers and the
> > payload_len from IPv6 headers to compute the total number of bytes to be
> > included in the checksum.
> > 
> > To address the fact that skb->csum is invalid when a padded frame is
> > received I have updated the code to fall though to the CHECKSUM_NONE path
> > for CHECKSUM_COMPLETE frames that contain padding.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
> 
> Nack.  This is needlessly complex.  As I said before, please
> just do a pskb_trim_rcsum in inet_gro_receive and its IPv6
> counterpart and this should all just work.

Actually I take that back.  You are right that the preference is to
flush and not trim, since we want to preserve the incoming packet in
its exact form.

So can you tell me a bit more about the padding? Is it added by the
NIC or did it come from the remote side?

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html