diff mbox series

[v2] KEYS: asymmetric: Copy sig and digest in public_key_verify_signature()

Message ID 20221209150633.1033556-1-roberto.sassu@huaweicloud.com (mailing list archive)
State New
Headers show
Series [v2] KEYS: asymmetric: Copy sig and digest in public_key_verify_signature() | expand

Commit Message

Roberto Sassu Dec. 9, 2022, 3:06 p.m. UTC
From: Roberto Sassu <roberto.sassu@huawei.com>

Commit ac4e97abce9b8 ("scatterlist: sg_set_buf() argument must be in linear
mapping") checks that both the signature and the digest reside in the
linear mapping area.

However, more recently commit ba14a194a434c ("fork: Add generic vmalloced
stack support"), made it possible to move the stack in the vmalloc area,
which is not contiguous, and thus not suitable for sg_set_buf() which needs
adjacent pages.

Always make a copy of the signature and digest in the same buffer used to
store the key and its parameters, and pass them to sg_set_buf(). Prefer it
to conditionally doing the copy if necessary, to keep the code simple. The
buffer allocated with kmalloc() is in the linear mapping area.

Cc: stable@vger.kernel.org # 4.9.x
Fixes: ba14a194a434 ("fork: Add generic vmalloced stack support")
Link: https://lore.kernel.org/linux-integrity/Y4pIpxbjBdajymBJ@sol.localdomain/
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
---
 crypto/asymmetric_keys/public_key.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

Comments

Eric Biggers Dec. 9, 2022, 7:04 p.m. UTC | #1
On Fri, Dec 09, 2022 at 04:06:33PM +0100, Roberto Sassu wrote:
> +	/* key is used to store the sig and digest too. */
> +	key = kmalloc(key_max_len, GFP_KERNEL);
>  	if (!key)
>  		goto error_free_req;

Maybe just call this 'buf', as the key is just one of the purposes the buffer is
used for now.

> +	/* Cannot use one scatterlist. The first needs to be s->s_size long. */
> +	sg_set_buf(&src_sg[0], key, sig->s_size);
> +	sg_set_buf(&src_sg[1], key + sig->s_size, sig->digest_size);
>  	akcipher_request_set_crypt(req, src_sg, NULL, sig->s_size,
>  				   sig->digest_size);

AFAIK, none of the crypto APIs that operate on 'scatterlist' are supposed to
care how the data is divided up into scatterlist elements.  So it sounds like
there is another bug that needs to be fixed.  It should be fixed, not worked
around.

- Eric
Roberto Sassu Dec. 12, 2022, 9:07 a.m. UTC | #2
On Fri, 2022-12-09 at 11:04 -0800, Eric Biggers wrote:
> On Fri, Dec 09, 2022 at 04:06:33PM +0100, Roberto Sassu wrote:
> > +	/* key is used to store the sig and digest too. */
> > +	key = kmalloc(key_max_len, GFP_KERNEL);
> >  	if (!key)
> >  		goto error_free_req;
> 
> Maybe just call this 'buf', as the key is just one of the purposes the buffer is
> used for now.

Yes, better.

> > +	/* Cannot use one scatterlist. The first needs to be s->s_size long. */
> > +	sg_set_buf(&src_sg[0], key, sig->s_size);
> > +	sg_set_buf(&src_sg[1], key + sig->s_size, sig->digest_size);
> >  	akcipher_request_set_crypt(req, src_sg, NULL, sig->s_size,
> >  				   sig->digest_size);
> 
> AFAIK, none of the crypto APIs that operate on 'scatterlist' are supposed to
> care how the data is divided up into scatterlist elements.  So it sounds like
> there is another bug that needs to be fixed.  It should be fixed, not worked
> around.

The problem is a misalignment between req->src_len (set to sig->s_size
by akcipher_request_set_crypt()) and the length of the scatterlist (if
we set the latter to sig->s_size + sig->digest_size).

When rsa_enc() calls mpi_read_raw_from_sgl(), it passes req->src_len as
argument, and the latter allocates the MPI according to that. However,
it does parsing depending on the length of the scatterlist.

If there are two scatterlists, it is not a problem, there is no
misalignment. mpi_read_raw_from_sgl() picks the first. If there is just
one, mpi_read_raw_from_sgl() parses all data there.

Roberto
Herbert Xu Dec. 12, 2022, 9:15 a.m. UTC | #3
On Mon, Dec 12, 2022 at 10:07:38AM +0100, Roberto Sassu wrote:
>
> The problem is a misalignment between req->src_len (set to sig->s_size
> by akcipher_request_set_crypt()) and the length of the scatterlist (if
> we set the latter to sig->s_size + sig->digest_size).
> 
> When rsa_enc() calls mpi_read_raw_from_sgl(), it passes req->src_len as
> argument, and the latter allocates the MPI according to that. However,
> it does parsing depending on the length of the scatterlist.
> 
> If there are two scatterlists, it is not a problem, there is no
> misalignment. mpi_read_raw_from_sgl() picks the first. If there is just
> one, mpi_read_raw_from_sgl() parses all data there.

Thanks for the explanation.  That's definitely a bug which should
be fixed either in the RSA code or in MPI.

I'll look into it.

Cheers,
Roberto Sassu Dec. 19, 2022, 8:49 a.m. UTC | #4
On Mon, 2022-12-12 at 17:15 +0800, Herbert Xu wrote:
> On Mon, Dec 12, 2022 at 10:07:38AM +0100, Roberto Sassu wrote:
> > The problem is a misalignment between req->src_len (set to sig->s_size
> > by akcipher_request_set_crypt()) and the length of the scatterlist (if
> > we set the latter to sig->s_size + sig->digest_size).
> > 
> > When rsa_enc() calls mpi_read_raw_from_sgl(), it passes req->src_len as
> > argument, and the latter allocates the MPI according to that. However,
> > it does parsing depending on the length of the scatterlist.
> > 
> > If there are two scatterlists, it is not a problem, there is no
> > misalignment. mpi_read_raw_from_sgl() picks the first. If there is just
> > one, mpi_read_raw_from_sgl() parses all data there.
> 
> Thanks for the explanation.  That's definitely a bug which should
> be fixed either in the RSA code or in MPI.
> 
> I'll look into it.

Hi Herbert

do you have any news on this bug?

Thanks

Roberto
diff mbox series

Patch

diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
index 2f8352e88860..ccc091119972 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -363,6 +363,7 @@  int public_key_verify_signature(const struct public_key *pkey,
 	struct scatterlist src_sg[2];
 	char alg_name[CRYPTO_MAX_ALG_NAME];
 	char *key, *ptr;
+	u32 key_max_len;
 	int ret;
 
 	pr_devel("==>%s()\n", __func__);
@@ -400,8 +401,12 @@  int public_key_verify_signature(const struct public_key *pkey,
 	if (!req)
 		goto error_free_tfm;
 
-	key = kmalloc(pkey->keylen + sizeof(u32) * 2 + pkey->paramlen,
-		      GFP_KERNEL);
+	key_max_len = max_t(u32,
+			    pkey->keylen + sizeof(u32) * 2 + pkey->paramlen,
+			    sig->s_size + sig->digest_size);
+
+	/* key is used to store the sig and digest too. */
+	key = kmalloc(key_max_len, GFP_KERNEL);
 	if (!key)
 		goto error_free_req;
 
@@ -424,9 +429,13 @@  int public_key_verify_signature(const struct public_key *pkey,
 			goto error_free_key;
 	}
 
+	memcpy(key, sig->s, sig->s_size);
+	memcpy(key + sig->s_size, sig->digest, sig->digest_size);
+
 	sg_init_table(src_sg, 2);
-	sg_set_buf(&src_sg[0], sig->s, sig->s_size);
-	sg_set_buf(&src_sg[1], sig->digest, sig->digest_size);
+	/* Cannot use one scatterlist. The first needs to be s->s_size long. */
+	sg_set_buf(&src_sg[0], key, sig->s_size);
+	sg_set_buf(&src_sg[1], key + sig->s_size, sig->digest_size);
 	akcipher_request_set_crypt(req, src_sg, NULL, sig->s_size,
 				   sig->digest_size);
 	crypto_init_wait(&cwait);