From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751147AbdALHwc (ORCPT ); Thu, 12 Jan 2017 02:52:32 -0500 Received: from mail-ua0-f174.google.com ([209.85.217.174]:34770 "EHLO mail-ua0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751117AbdALHw3 (ORCPT ); Thu, 12 Jan 2017 02:52:29 -0500 MIME-Version: 1.0 In-Reply-To: <20170112074752.GA14230@gondor.apana.org.au> References: <890f4bdb28a1cf72f6b802b220b35ebaf0f76bb9.1484090585.git.luto@kernel.org> <20170112074752.GA14230@gondor.apana.org.au> From: Andy Lutomirski Date: Wed, 11 Jan 2017 23:52:03 -0800 Message-ID: Subject: Re: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests To: Herbert Xu Cc: Andy Lutomirski , Daniel Borkmann , Network Development , "linux-kernel@vger.kernel.org" , Linux Crypto Mailing List , "Jason A. Donenfeld" , Hannes Frederic Sowa , Alexei Starovoitov , Eric Dumazet , Eric Biggers , Tom Herbert , "David S. Miller" , Ard Biesheuvel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 11, 2017 at 11:47 PM, Herbert Xu wrote: > Andy Lutomirski wrote: >> There are some hashes (e.g. sha224) that have some internal trickery >> to make sure that only the correct number of output bytes are >> generated. If something goes wrong, they could potentially overrun >> the output buffer. >> >> Make the test more robust by allocating only enough space for the >> correct output size so that memory debugging will catch the error if >> the output is overrun. >> >> Tested by intentionally breaking sha224 to output all 256 >> internally-generated bits while running on KASAN. >> >> Cc: Ard Biesheuvel >> Cc: Herbert Xu >> Signed-off-by: Andy Lutomirski > > This patch doesn't seem to depend on anything else in the series. > Do you want me to take it separately? Yes, please. Its only relation to the rest of the series is that I wanted to make sure that I didn't mess up sha224's finalization code. --Andy