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: Wed, 04 Mar 2015 10:22:44 -0800 From: Alexander Duyck <alexander.h.duyck@...hat.com> To: David Miller <davem@...emloft.net> CC: netdev@...r.kernel.org Subject: Re: [net-next PATCH 0/6] ipv4/fib_trie: Cleanups to prepare for introduction of key vector On 03/04/2015 09:53 AM, David Miller wrote: > From: Alexander Duyck <alexander.h.duyck@...hat.com> > Date: Wed, 04 Mar 2015 06:51:27 -0800 > >> If bits can be 32 then idx should be an unsigned long which is 64 >> bits. > unsigned long is 32-bit on 32-bit platforms Right, but if unsigned long is 32 bits then usually a pointer is as well. As a result we wouldn't be able to access the upper bits of a node with bits == 32 since the size of the tnode would be over 4 * 2^32. The general idea is the vmalloc should fail when we attempt to allocate a bits == 32 tnode on a system w/ only 32b longs. Then again I think we will probably cause a memory corruption on a 32b system since we are probably overflowing size_t on the allocation if bits ==32. I'll have to take a look as I believe we are using the offsetof macro and I am not sure how that handles a 64b address on a 32b system. - Alex -- 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
Powered by blists - more mailing lists