[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWWt33=03gbBs73NkBOunZU+req1BLgUNcEMfh3T1AXUA@mail.gmail.com>
Date: Wed, 14 Dec 2016 08:22:52 -0800
From: Andy Lutomirski <luto@...capital.net>
To: David Howells <dhowells@...hat.com>
Cc: Andy Lutomirski <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>, keyrings@...r.kernel.org,
Eric Biggers <ebiggers3@...il.com>,
linux-crypto@...r.kernel.org,
Herbert Xu <herbert@...dor.apana.org.au>,
Stephan Mueller <smueller@...onox.de>
Subject: Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs
On Wed, Dec 14, 2016 at 12:37 AM, David Howells <dhowells@...hat.com> wrote:
> Andy Lutomirski <luto@...capital.net> 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
Powered by blists - more mailing lists