From: Roberto Sassu <[email protected]>
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: [email protected] # 4.9.x
Fixes: ba14a194a434 ("fork: Add generic vmalloced stack support")
Link: https://lore.kernel.org/linux-integrity/[email protected]/
Suggested-by: Eric Biggers <[email protected]>
Signed-off-by: Roberto Sassu <[email protected]>
---
crypto/asymmetric_keys/public_key.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
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);
--
2.25.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
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
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,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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
On Mon, Dec 19, 2022 at 09:49:29AM +0100, Roberto Sassu wrote:
>
> do you have any news on this bug?
Thanks for the reminder. Could you please try this patch?
---8<---
The helper mpi_read_raw_from_sgl ignores the second parameter
nbytes when reading the SG list and may overrun its own buffer
because it only allocates enough memory according to nbytes.
Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
Reported-by: Roberto Sassu <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index 39c4c6731094..6bffc68c1a5a 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -494,17 +494,15 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
val->sign = 0;
val->nlimbs = nlimbs;
- if (nbytes == 0)
- return val;
-
j = nlimbs - 1;
a = 0;
z = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
z %= BYTES_PER_MPI_LIMB;
- while (sg_miter_next(&miter)) {
+ while (nbytes && sg_miter_next(&miter)) {
buff = miter.addr;
- len = miter.length;
+ len = min_t(unsigned, miter.length, nbytes);
+ nbytes -= len;
for (x = 0; x < len; x++) {
a <<= 8;
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On 12/20/2022 8:24 AM, Herbert Xu wrote:
> On Mon, Dec 19, 2022 at 09:49:29AM +0100, Roberto Sassu wrote:
>>
>> do you have any news on this bug?
>
> Thanks for the reminder. Could you please try this patch?
Tried, could not boot the UML kernel.
After looking, it seems we have to call sg_miter_stop(). Or
alternatively, we could let sg_miter_next() be called but not writing
anything inside the loop.
With either of those fixes, the tests pass (using one scatterlist).
Roberto
> ---8<---
> The helper mpi_read_raw_from_sgl ignores the second parameter
> nbytes when reading the SG list and may overrun its own buffer
> because it only allocates enough memory according to nbytes.
>
> Fixes: 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers")
> Reported-by: Roberto Sassu <[email protected]>
> Signed-off-by: Herbert Xu <[email protected]>
>
> diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
> index 39c4c6731094..6bffc68c1a5a 100644
> --- a/lib/mpi/mpicoder.c
> +++ b/lib/mpi/mpicoder.c
> @@ -494,17 +494,15 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl, unsigned int nbytes)
> val->sign = 0;
> val->nlimbs = nlimbs;
>
> - if (nbytes == 0)
> - return val;
> -
> j = nlimbs - 1;
> a = 0;
> z = BYTES_PER_MPI_LIMB - nbytes % BYTES_PER_MPI_LIMB;
> z %= BYTES_PER_MPI_LIMB;
>
> - while (sg_miter_next(&miter)) {
> + while (nbytes && sg_miter_next(&miter)) {
> buff = miter.addr;
> - len = miter.length;
> + len = min_t(unsigned, miter.length, nbytes);
> + nbytes -= len;
>
> for (x = 0; x < len; x++) {
> a <<= 8;