From: "Jason A. Donenfeld" Subject: Re: [PATCH v3] siphash: add cryptographically secure hashtable function Date: Tue, 13 Dec 2016 23:43:06 +0100 Message-ID: References: <20161212221832.10653-1-Jason@zx2c4.com> <20161213083948.GA8994@zzz> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Linus Torvalds , "kernel-hardening@lists.openwall.com" , LKML , Linux Crypto Mailing List , George Spelvin , Scott Bauer , Andi Kleen , Andy Lutomirski , Greg KH , Jean-Philippe Aumasson , "Daniel J . Bernstein" To: Eric Biggers Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <20161213083948.GA8994@zzz> List-Id: linux-crypto.vger.kernel.org Hi Eric, On Tue, Dec 13, 2016 at 9:39 AM, Eric Biggers wrote: > Hmm, I don't think you can really do load_unaligned_zeropad() without first > checking for 'left != 0'. The fixup section for load_unaligned_zeropad() > assumes that rounding the pointer down to a word boundary will produce an > address from which an 'unsigned long' can be loaded. But if 'left = 0' and we > happen to be on a page boundary with the next page unmapped, then this will not > be true and the second load will still fault. Excellent point. I haven't been able to trigger this in my experiments, but it doesn't look like there's much to prevent this from happening. I'll submit a v4 with this as fixed, since there hasn't been any other code quality issues. Jason