From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765132AbdAKPOA convert rfc822-to-8bit (ORCPT ); Wed, 11 Jan 2017 10:14:00 -0500 Received: from smtp-out4.electric.net ([192.162.216.188]:50694 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765059AbdAKPN4 (ORCPT ); Wed, 11 Jan 2017 10:13:56 -0500 From: David Laight To: "'Andy Lutomirski'" , Daniel Borkmann , Netdev , LKML , Linux Crypto Mailing List CC: "Jason A. Donenfeld" , Hannes Frederic Sowa , Alexei Starovoitov , Eric Dumazet , "Eric Biggers" , Tom Herbert , "David S. Miller" , Ard Biesheuvel , Herbert Xu Subject: RE: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests Thread-Topic: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests Thread-Index: AQHSa5kfyWipJH+K10GlkP6k9rIQ2aEzYu8A Date: Wed, 11 Jan 2017 15:13:40 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB025EE7B@AcuExch.aculab.com> References: <890f4bdb28a1cf72f6b802b220b35ebaf0f76bb9.1484090585.git.luto@kernel.org> In-Reply-To: <890f4bdb28a1cf72f6b802b220b35ebaf0f76bb9.1484090585.git.luto@kernel.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andy Lutomirski > Sent: 10 January 2017 23:25 > 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. Might be better to test this by allocating an overlong buffer and then explicitly checking that the output hasn't overrun the allowed space. If nothing else the error message will be clearer. David