* [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2()
@ 2022-01-13 20:04 Eric Biggers
2022-01-15 18:45 ` Jarkko Sakkinen
0 siblings, 1 reply; 6+ messages in thread
From: Eric Biggers @ 2022-01-13 20:04 UTC (permalink / raw)
To: keyrings, David Howells, Jarkko Sakkinen
Cc: linux-crypto, Marcel Holtmann, Denis Kenzior, stable
From: Eric Biggers <ebiggers@google.com>
In many cases, keyctl_pkey_params_get_2() is validating the user buffer
lengths against the wrong algorithm properties. Fix it to check against
the correct properties.
Probably this wasn't noticed before because for all asymmetric keys of
the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
== max_dec_size. However, this isn't necessarily true for the
"asym_tpm" subtype (it should be, but it's not strictly validated). Of
course, future key types could have different values as well.
Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
security/keys/keyctl_pkey.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
index 5de0d599a274..97bc27bbf079 100644
--- a/security/keys/keyctl_pkey.c
+++ b/security/keys/keyctl_pkey.c
@@ -135,15 +135,23 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
switch (op) {
case KEYCTL_PKEY_ENCRYPT:
+ if (uparams.in_len > info.max_dec_size ||
+ uparams.out_len > info.max_enc_size)
+ return -EINVAL;
+ break;
case KEYCTL_PKEY_DECRYPT:
if (uparams.in_len > info.max_enc_size ||
uparams.out_len > info.max_dec_size)
return -EINVAL;
break;
case KEYCTL_PKEY_SIGN:
+ if (uparams.in_len > info.max_data_size ||
+ uparams.out_len > info.max_sig_size)
+ return -EINVAL;
+ break;
case KEYCTL_PKEY_VERIFY:
- if (uparams.in_len > info.max_sig_size ||
- uparams.out_len > info.max_data_size)
+ if (uparams.in_len > info.max_data_size ||
+ uparams.in2_len > info.max_sig_size)
return -EINVAL;
break;
default:
@@ -151,7 +159,7 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
}
params->in_len = uparams.in_len;
- params->out_len = uparams.out_len;
+ params->out_len = uparams.out_len; /* Note: same as in2_len */
return 0;
}
base-commit: feb7a43de5ef625ad74097d8fd3481d5dbc06a59
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2()
2022-01-13 20:04 [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2() Eric Biggers
@ 2022-01-15 18:45 ` Jarkko Sakkinen
2022-01-15 19:53 ` Eric Biggers
0 siblings, 1 reply; 6+ messages in thread
From: Jarkko Sakkinen @ 2022-01-15 18:45 UTC (permalink / raw)
To: Eric Biggers
Cc: keyrings, David Howells, linux-crypto, Marcel Holtmann,
Denis Kenzior, stable
On Thu, Jan 13, 2022 at 12:04:54PM -0800, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> In many cases, keyctl_pkey_params_get_2() is validating the user buffer
> lengths against the wrong algorithm properties. Fix it to check against
> the correct properties.
>
> Probably this wasn't noticed before because for all asymmetric keys of
> the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
> == max_dec_size. However, this isn't necessarily true for the
> "asym_tpm" subtype (it should be, but it's not strictly validated). Of
> course, future key types could have different values as well.
With a quick look, asym_tpm is TPM 1.x only, which only has 2048-bit RSA
keys.
> Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
> Cc: <stable@vger.kernel.org> # v4.20+
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> security/keys/keyctl_pkey.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
> index 5de0d599a274..97bc27bbf079 100644
> --- a/security/keys/keyctl_pkey.c
> +++ b/security/keys/keyctl_pkey.c
> @@ -135,15 +135,23 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
>
> switch (op) {
> case KEYCTL_PKEY_ENCRYPT:
> + if (uparams.in_len > info.max_dec_size ||
> + uparams.out_len > info.max_enc_size)
> + return -EINVAL;
> + break;
> case KEYCTL_PKEY_DECRYPT:
> if (uparams.in_len > info.max_enc_size ||
> uparams.out_len > info.max_dec_size)
> return -EINVAL;
> break;
> case KEYCTL_PKEY_SIGN:
> + if (uparams.in_len > info.max_data_size ||
> + uparams.out_len > info.max_sig_size)
> + return -EINVAL;
> + break;
> case KEYCTL_PKEY_VERIFY:
> - if (uparams.in_len > info.max_sig_size ||
> - uparams.out_len > info.max_data_size)
> + if (uparams.in_len > info.max_data_size ||
> + uparams.in2_len > info.max_sig_size)
> return -EINVAL;
> break;
> default:
> @@ -151,7 +159,7 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
> }
>
> params->in_len = uparams.in_len;
> - params->out_len = uparams.out_len;
> + params->out_len = uparams.out_len; /* Note: same as in2_len */
> return 0;
> }
>
>
> base-commit: feb7a43de5ef625ad74097d8fd3481d5dbc06a59
> --
> 2.34.1
>
/Jarkko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2()
2022-01-15 18:45 ` Jarkko Sakkinen
@ 2022-01-15 19:53 ` Eric Biggers
2022-01-15 21:26 ` Jarkko Sakkinen
0 siblings, 1 reply; 6+ messages in thread
From: Eric Biggers @ 2022-01-15 19:53 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: keyrings, David Howells, linux-crypto, Marcel Holtmann,
Denis Kenzior, stable
On Sat, Jan 15, 2022 at 08:45:03PM +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 13, 2022 at 12:04:54PM -0800, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > In many cases, keyctl_pkey_params_get_2() is validating the user buffer
> > lengths against the wrong algorithm properties. Fix it to check against
> > the correct properties.
> >
> > Probably this wasn't noticed before because for all asymmetric keys of
> > the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
> > == max_dec_size. However, this isn't necessarily true for the
> > "asym_tpm" subtype (it should be, but it's not strictly validated). Of
> > course, future key types could have different values as well.
>
> With a quick look, asym_tpm is TPM 1.x only, which only has 2048-bit RSA
> keys.
The code allows other lengths, as well as the case where the "RSA key size"
doesn't match the "public key size". Probably both are bugs and they should
both be 256 bytes (2048 bits) only. Anyway, that would be a separate fix.
- Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2()
2022-01-15 19:53 ` Eric Biggers
@ 2022-01-15 21:26 ` Jarkko Sakkinen
2022-01-19 0:22 ` Eric Biggers
0 siblings, 1 reply; 6+ messages in thread
From: Jarkko Sakkinen @ 2022-01-15 21:26 UTC (permalink / raw)
To: Eric Biggers
Cc: keyrings, David Howells, linux-crypto, Marcel Holtmann,
Denis Kenzior, stable
On Sat, Jan 15, 2022 at 11:53:34AM -0800, Eric Biggers wrote:
> On Sat, Jan 15, 2022 at 08:45:03PM +0200, Jarkko Sakkinen wrote:
> > On Thu, Jan 13, 2022 at 12:04:54PM -0800, Eric Biggers wrote:
> > > From: Eric Biggers <ebiggers@google.com>
> > >
> > > In many cases, keyctl_pkey_params_get_2() is validating the user buffer
> > > lengths against the wrong algorithm properties. Fix it to check against
> > > the correct properties.
> > >
> > > Probably this wasn't noticed before because for all asymmetric keys of
> > > the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
> > > == max_dec_size. However, this isn't necessarily true for the
> > > "asym_tpm" subtype (it should be, but it's not strictly validated). Of
> > > course, future key types could have different values as well.
> >
> > With a quick look, asym_tpm is TPM 1.x only, which only has 2048-bit RSA
> > keys.
>
> The code allows other lengths, as well as the case where the "RSA key size"
> doesn't match the "public key size". Probably both are bugs and they should
> both be 256 bytes (2048 bits) only. Anyway, that would be a separate fix.
>
> - Eric
I'm fine with the current commit message. E.g. I have no idea at this
point whether there should be in future separate asym_tpm2 or all bundled
to asym_tpm.
Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2()
2022-01-15 21:26 ` Jarkko Sakkinen
@ 2022-01-19 0:22 ` Eric Biggers
2022-01-26 14:06 ` Jarkko Sakkinen
0 siblings, 1 reply; 6+ messages in thread
From: Eric Biggers @ 2022-01-19 0:22 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: keyrings, David Howells, linux-crypto, Marcel Holtmann,
Denis Kenzior, stable
On Sat, Jan 15, 2022 at 11:26:16PM +0200, Jarkko Sakkinen wrote:
> On Sat, Jan 15, 2022 at 11:53:34AM -0800, Eric Biggers wrote:
> > On Sat, Jan 15, 2022 at 08:45:03PM +0200, Jarkko Sakkinen wrote:
> > > On Thu, Jan 13, 2022 at 12:04:54PM -0800, Eric Biggers wrote:
> > > > From: Eric Biggers <ebiggers@google.com>
> > > >
> > > > In many cases, keyctl_pkey_params_get_2() is validating the user buffer
> > > > lengths against the wrong algorithm properties. Fix it to check against
> > > > the correct properties.
> > > >
> > > > Probably this wasn't noticed before because for all asymmetric keys of
> > > > the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
> > > > == max_dec_size. However, this isn't necessarily true for the
> > > > "asym_tpm" subtype (it should be, but it's not strictly validated). Of
> > > > course, future key types could have different values as well.
> > >
> > > With a quick look, asym_tpm is TPM 1.x only, which only has 2048-bit RSA
> > > keys.
> >
> > The code allows other lengths, as well as the case where the "RSA key size"
> > doesn't match the "public key size". Probably both are bugs and they should
> > both be 256 bytes (2048 bits) only. Anyway, that would be a separate fix.
> >
> > - Eric
>
> I'm fine with the current commit message. E.g. I have no idea at this
> point whether there should be in future separate asym_tpm2 or all bundled
> to asym_tpm.
>
> Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
>
Okay, great. Just to be clear, I'm expecting either you or David
(maintainer:KEYS/KEYRINGS) to apply this patch. Acked-by is usually given by a
maintainer when someone else applies a patch.
- Eric
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2()
2022-01-19 0:22 ` Eric Biggers
@ 2022-01-26 14:06 ` Jarkko Sakkinen
0 siblings, 0 replies; 6+ messages in thread
From: Jarkko Sakkinen @ 2022-01-26 14:06 UTC (permalink / raw)
To: Eric Biggers
Cc: keyrings, David Howells, linux-crypto, Marcel Holtmann,
Denis Kenzior, stable
On Tue, Jan 18, 2022 at 04:22:22PM -0800, Eric Biggers wrote:
> On Sat, Jan 15, 2022 at 11:26:16PM +0200, Jarkko Sakkinen wrote:
> > On Sat, Jan 15, 2022 at 11:53:34AM -0800, Eric Biggers wrote:
> > > On Sat, Jan 15, 2022 at 08:45:03PM +0200, Jarkko Sakkinen wrote:
> > > > On Thu, Jan 13, 2022 at 12:04:54PM -0800, Eric Biggers wrote:
> > > > > From: Eric Biggers <ebiggers@google.com>
> > > > >
> > > > > In many cases, keyctl_pkey_params_get_2() is validating the user buffer
> > > > > lengths against the wrong algorithm properties. Fix it to check against
> > > > > the correct properties.
> > > > >
> > > > > Probably this wasn't noticed before because for all asymmetric keys of
> > > > > the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
> > > > > == max_dec_size. However, this isn't necessarily true for the
> > > > > "asym_tpm" subtype (it should be, but it's not strictly validated). Of
> > > > > course, future key types could have different values as well.
> > > >
> > > > With a quick look, asym_tpm is TPM 1.x only, which only has 2048-bit RSA
> > > > keys.
> > >
> > > The code allows other lengths, as well as the case where the "RSA key size"
> > > doesn't match the "public key size". Probably both are bugs and they should
> > > both be 256 bytes (2048 bits) only. Anyway, that would be a separate fix.
> > >
> > > - Eric
> >
> > I'm fine with the current commit message. E.g. I have no idea at this
> > point whether there should be in future separate asym_tpm2 or all bundled
> > to asym_tpm.
> >
> > Acked-by: Jarkko Sakkinen <jarkko@kernel.org>
> >
>
> Okay, great. Just to be clear, I'm expecting either you or David
> (maintainer:KEYS/KEYRINGS) to apply this patch. Acked-by is usually given by a
> maintainer when someone else applies a patch.
I changed it to reviewed-by and applied.
BR, Jarkko
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-26 14:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-13 20:04 [PATCH] KEYS: fix length validation in keyctl_pkey_params_get_2() Eric Biggers
2022-01-15 18:45 ` Jarkko Sakkinen
2022-01-15 19:53 ` Eric Biggers
2022-01-15 21:26 ` Jarkko Sakkinen
2022-01-19 0:22 ` Eric Biggers
2022-01-26 14:06 ` Jarkko Sakkinen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.