linux-kernel - Re: [GIT PULL] Asymmetric keys fix for v6.4-rc5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230603160208.GA677@quark.localdomain>
Date:   Sat, 3 Jun 2023 09:02:08 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Roberto Sassu <roberto.sassu@...weicloud.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Stefan Berger <stefanb@...ux.ibm.com>, davem@...emloft.net,
        zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
        paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
        Jarkko Sakkinen <jarkko@...nel.org>,
        linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [GIT PULL] Asymmetric keys fix for v6.4-rc5

On Sat, Jun 03, 2023 at 12:41:00PM +0200, Roberto Sassu wrote:
> On 6/3/2023 2:02 AM, Linus Torvalds wrote:
> > On Fri, Jun 2, 2023 at 1:38 PM Linus Torvalds
> > <torvalds@...ux-foundation.org> wrote:
> > > 
> > > The patch re-uses the allocation it already does for the key data, and
> > > it seems sane.
> > 
> > Ugh. I had to check that it was ok to re-use the key buffer, but it
> > does seem to be the case that you can just re-use the buffer after
> > you've done that crypto_akcipher_set_priv/pub_key() call, and the
> > crypto layer has to copy it into its own data structures.
> 
> Yes, we could not do it if the set_pub_key/set_priv_key methods use
> internally the passed pointer. I guess it depends on the methods, for RSA
> and ECDSA it seems fine (they copy to a different location).
> 
> The doubt comes because the buffer is freed after crypto_wait_req() and not
> after crypto_akcipher_set_*_key(), suggesting that it could be actually used
> during the crypto operation.
> 
> Rechecked the thread, and the suggestion to reuse the buffer and not append
> the signature and digest at the end was by Eric Biggers.
> 
> Eric, in light of this finding, should we still reuse the buffer?
> 

I don't think there was any "finding" here.  The setkey methods in the crypto
API aren't allowed to reuse the buffer they are passed, so the patch is fine.

- Eric