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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 01 Mar 2016 16:35:44 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	alexander.duyck@...il.com
Cc:	aduyck@...antis.com, netdev@...r.kernel.org
Subject: Re: [net-next PATCH] IPv6: Use a 16 bit length field when
 computing a IPv6 UDP checksum

From: Alexander Duyck <alexander.duyck@...il.com>
Date: Tue, 1 Mar 2016 13:19:28 -0800

> I was wondering what your thoughts would be about widening the size of
> the length field that we pass into csum_tcpudp_magic from a 16 bit to
> a 24 or 32 bit value?  The general idea would be to shift tunnels over
> to uniformly using skb->len instead of a mix of 16 bit or 32 bit
> lengths.  My thought is it might add a bit of security since it would
> invalidate the outer header checksum for the case where length has
> exceeded 65535 resulting in uh->len field being invalid anyway.

Hmmm, but wait, what is uh->len supposed to be for an ipv6 jumbogram
anyways?

It just gets truncated and the the ipv6 header payload length field
trumps whatever is in the UDP header length field right?

If that's what happens then we should uniformly use the truncated
length for the pseudo-header calculations as you originally suggested.

How UDP jumbograms as supposed to be handled wrt. udp_hdr->len should
guide our implementation.

Powered by blists - more mailing lists