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
| ||
|
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