Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932671AbcLNQXQ (ORCPT ); Wed, 14 Dec 2016 11:23:16 -0500 Received: from mail-vk0-f45.google.com ([209.85.213.45]:34734 "EHLO mail-vk0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755856AbcLNQXO (ORCPT ); Wed, 14 Dec 2016 11:23:14 -0500 MIME-Version: 1.0 In-Reply-To: <18039.1481704679@warthog.procyon.org.uk> References: <627e948e37314c13a67c90917386c814c56b8e20.1481683609.git.luto@kernel.org> <18039.1481704679@warthog.procyon.org.uk> From: Andy Lutomirski Date: Wed, 14 Dec 2016 08:22:52 -0800 Message-ID: Subject: Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs To: David Howells Cc: Andy Lutomirski , "linux-kernel@vger.kernel.org" , USB list , keyrings@vger.kernel.org, Eric Biggers , linux-crypto@vger.kernel.org, Herbert Xu , Stephan Mueller Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1045 Lines: 31 On Wed, Dec 14, 2016 at 12:37 AM, David Howells wrote: > Andy Lutomirski wrote: > >> > - sg_set_buf(&sg_out[1], pad, sizeof pad); >> > + sg_set_buf(&sg_out[1], empty_zero_page, 16); >> >> My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what >> exactly is the code trying to do? The old code makes no sense. It's >> setting the *output* buffer to zeroed padding. > > Padding goes into the encrypt function and is going to come out of the decrypt > function. Possibly derived_key_decrypt() should be checking that the padding > that comes out is actually a bunch of zeros. Maybe we don't actually need to > get the padding out, but I'm not sure whether the crypto layer will > malfunction if we don't give it a buffer for the padding. It was the memset that threw me for a loop. David, are these encrypted keys ever exported anywhere? If not, could the code use a mode that doesn't need padding? --Andy > > David -- Andy Lutomirski AMA Capital Management, LLC