Re: [PATCH 2/3] crypto: ccp - return an actual key size from RSA max_size callback

[Hook, Gary]

On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote:
> On 02.03.2018 17:44, Herbert Xu wrote:
> > On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote:
> > > rsa-pkcs1pad uses a value returned from a RSA implementation max_size
> > > callback as a size of an input buffer passed to the RSA implementation for
> > > encrypt and sign operations.
> > >
> > > CCP RSA implementation uses a hardware input buffer which size depends only
> > > on the current RSA key length, so it should return this key length in
> > > the max_size callback, too.
> > > This also matches what the kernel software RSA implementation does.
> > >
> > > Previously, the value returned from this callback was always the maximum
> > > RSA key size the CCP hardware supports.
> > > This resulted in this huge buffer being passed by rsa-pkcs1pad to CCP even
> > > for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd()
> > > tried to copy this large input buffer into a RSA key length-sized hardware
> > > input buffer.
> > >
> > > Signed-off-by: Maciej S. Szmigiero <mail@xxxxxxxxxxxxxxxxxxxxx>
> > > Fixes: ceeec0afd684 ("crypto: ccp - Add support for RSA on the CCP")
> > > Cc: stable@xxxxxxxxxxxxxxx
> >
> > Patch applied.  Thanks.
>
> Thanks.
>
> However, what about the first patch from this series?
> Without it, while it no longer should cause a buffer overflow, in-kernel
> X.509 certificate verification will still fail with CCP driver loaded
> (since CCP RSA implementation has a higher priority than the software
> RSA implementation).
>
> Maciej


I commented on that one here:
https://marc.info/?l=linux-crypto-vger&m=151986452422791&w=2

Effectively a NACK. We are a reviewing a proposed patch right now.