netdev - Re: [net-next PATCH] IPv6: Use a 16 bit length field when computing a IPv6 UDP 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 for Android: free password hash cracker in your pocket

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

Message-Id: <20160301.163544.1175023538158578123.davem@davemloft.net>
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.