[PATCH v2 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id

[PATCH v2 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id

[Thorsten Blum]

Use check_add_overflow() to guard against a potential integer overflow
when adding the binary blob lengths in asymmetric_key_generate_id() and
return -EOVERFLOW accordingly. This prevents a possible buffer overflow
when copying data from potentially malicious X.509 fields that can be
arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names,
etc.

Also use struct_size() to calculate the number of bytes to allocate for
the new asymmetric key id.

Cc: stable@vger.kernel.org
Fixes: 7901c1a8effb ("KEYS: Implement binary asymmetric key ID handling")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Use check_add_overflow() and error out as suggested by Lukas
- Update patch description
- Add Fixes: tag and @stable for backporting
- Link to v1: https://lore.kernel.org/lkml/20251007185220.234611-2-thorsten.blum@linux.dev/
---
 crypto/asymmetric_keys/asymmetric_type.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index ba2d9d1ea235..bd96f799757d 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -11,6 +11,7 @@
 #include <crypto/public_key.h>
 #include <linux/seq_file.h>
 #include <linux/module.h>
+#include <linux/overflow.h>
 #include <linux/slab.h>
 #include <linux/ctype.h>
 #include <keys/system_keyring.h>
@@ -141,12 +142,14 @@ struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1,
 						     size_t len_2)
 {
 	struct asymmetric_key_id *kid;
+	size_t len;
 
-	kid = kmalloc(sizeof(struct asymmetric_key_id) + len_1 + len_2,
-		      GFP_KERNEL);
+	if (check_add_overflow(len_1, len_2, &len))
+		return ERR_PTR(-EOVERFLOW);
+	kid = kmalloc(struct_size(kid, data, len), GFP_KERNEL);
 	if (!kid)
 		return ERR_PTR(-ENOMEM);
-	kid->len = len_1 + len_2;
+	kid->len = len;
 	memcpy(kid->data, val_1, len_1);
 	memcpy(kid->data + len_1, val_2, len_2);
 	return kid;
-- 
2.51.0

[PATCH v2 2/2] crypto: asymmetric_keys - simplify asymmetric_key_hex_to_key_id

[Thorsten Blum]

Use struct_size() to calculate the number of bytes to allocate for the
asymmetric key id. Add a local variable to store the hex data length
instead of recalculating it.

Return and forward the error code from __asymmetric_key_hex_to_key_id()
directly instead of manually returning -EINVAL.

No functional change.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Changes in v2:
- Keep 'ret' and forward the errno from __asymmetric_key_hex_to_key_id()
  as suggested by Lukas
- Link to v1: https://lore.kernel.org/lkml/20251007185220.234611-3-thorsten.blum@linux.dev/
---
 crypto/asymmetric_keys/asymmetric_type.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index bd96f799757d..abd5cf419f83 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -229,6 +229,7 @@ struct asymmetric_key_id *asymmetric_key_hex_to_key_id(const char *id)
 {
 	struct asymmetric_key_id *match_id;
 	size_t asciihexlen;
+	size_t hexlen;
 	int ret;
 
 	if (!*id)
@@ -237,14 +238,14 @@ struct asymmetric_key_id *asymmetric_key_hex_to_key_id(const char *id)
 	if (asciihexlen & 1)
 		return ERR_PTR(-EINVAL);
 
-	match_id = kmalloc(sizeof(struct asymmetric_key_id) + asciihexlen / 2,
-			   GFP_KERNEL);
+	hexlen = asciihexlen / 2;
+	match_id = kmalloc(struct_size(match_id, data, hexlen), GFP_KERNEL);
 	if (!match_id)
 		return ERR_PTR(-ENOMEM);
-	ret = __asymmetric_key_hex_to_key_id(id, match_id, asciihexlen / 2);
+	ret = __asymmetric_key_hex_to_key_id(id, match_id, hexlen);
 	if (ret < 0) {
 		kfree(match_id);
-		return ERR_PTR(-EINVAL);
+		return ERR_PTR(ret);
 	}
 	return match_id;
 }
-- 
2.51.0

Re: [PATCH v2 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id

[Lukas Wunner]

On Sun, Oct 12, 2025 at 10:38:40PM +0200, Thorsten Blum wrote:
> Use check_add_overflow() to guard against a potential integer overflow
> when adding the binary blob lengths in asymmetric_key_generate_id() and
> return -EOVERFLOW accordingly. This prevents a possible buffer overflow
> when copying data from potentially malicious X.509 fields that can be
> arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names,
> etc.
> 
> Also use struct_size() to calculate the number of bytes to allocate for
> the new asymmetric key id.
> 
> Cc: stable@vger.kernel.org
> Fixes: 7901c1a8effb ("KEYS: Implement binary asymmetric key ID handling")

No stable designation please, this doesn't pass the "obviously correct"
test, see below.

> +++ b/crypto/asymmetric_keys/asymmetric_type.c
> @@ -141,12 +142,14 @@ struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1,
>  						     size_t len_2)
>  {
>  	struct asymmetric_key_id *kid;
> +	size_t len;
>  
> -	kid = kmalloc(sizeof(struct asymmetric_key_id) + len_1 + len_2,
> -		      GFP_KERNEL);
> +	if (check_add_overflow(len_1, len_2, &len))
> +		return ERR_PTR(-EOVERFLOW);
> +	kid = kmalloc(struct_size(kid, data, len), GFP_KERNEL);

This will add (at least) 2 bytes to len (namely the size of struct
asymmetric_key_id)) and may cause an overflow (even if len_1 + len_2
did not overflow).

struct_size() truncates to SIZE_MAX and then right below...

>  	if (!kid)
>  		return ERR_PTR(-ENOMEM);
> -	kid->len = len_1 + len_2;
> +	kid->len = len;
>  	memcpy(kid->data, val_1, len_1);
>  	memcpy(kid->data + len_1, val_2, len_2);

... this memcpy() operation will perform an out-of-bound access
beyond SIZE_MAX.

Thanks,

Lukas

Re: [PATCH v2 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id

[Thorsten Blum]

On 13. Oct 2025, at 08:24, Lukas Wunner wrote:
> On Sun, Oct 12, 2025 at 10:38:40PM +0200, Thorsten Blum wrote:
>> +++ b/crypto/asymmetric_keys/asymmetric_type.c
>> @@ -141,12 +142,14 @@ struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1,
>> 						     size_t len_2)
>> {
>> 	struct asymmetric_key_id *kid;
>> +	size_t len;
>> 
>> -	kid = kmalloc(sizeof(struct asymmetric_key_id) + len_1 + len_2,
>> -		      GFP_KERNEL);
>> +	if (check_add_overflow(len_1, len_2, &len))
>> +		return ERR_PTR(-EOVERFLOW);
>> +	kid = kmalloc(struct_size(kid, data, len), GFP_KERNEL);
> 
> This will add (at least) 2 bytes to len (namely the size of struct
> asymmetric_key_id)) and may cause an overflow (even if len_1 + len_2
> did not overflow).

Could you explain which part adds "(at least) 2 bytes to len"?

Thanks,
Thorsten

Re: [PATCH v2 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id

[Lukas Wunner]

On Mon, Oct 13, 2025 at 10:23:01AM +0200, Thorsten Blum wrote:
> On 13. Oct 2025, at 08:24, Lukas Wunner wrote:
> > On Sun, Oct 12, 2025 at 10:38:40PM +0200, Thorsten Blum wrote:
> >> +++ b/crypto/asymmetric_keys/asymmetric_type.c
> >> @@ -141,12 +142,14 @@ struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1,
> >> 						     size_t len_2)
> >> {
> >> 	struct asymmetric_key_id *kid;
> >> +	size_t len;
> >> 
> >> -	kid = kmalloc(sizeof(struct asymmetric_key_id) + len_1 + len_2,
> >> -		      GFP_KERNEL);
> >> +	if (check_add_overflow(len_1, len_2, &len))
> >> +		return ERR_PTR(-EOVERFLOW);
> >> +	kid = kmalloc(struct_size(kid, data, len), GFP_KERNEL);
> > 
> > This will add (at least) 2 bytes to len (namely the size of struct
> > asymmetric_key_id)) and may cause an overflow (even if len_1 + len_2
> > did not overflow).
> 
> Could you explain which part adds "(at least) 2 bytes to len"?

The struct_size() macro performs another size_add() to add the
size of struct asymmetric_key_id (which is at least 2 bytes) to len:

#define struct_size(p, member, count)					\
	__builtin_choose_expr(__is_constexpr(count),			\
		sizeof(*(p)) + flex_array_size(p, member, count),	\
		size_add(sizeof(*(p)), flex_array_size(p, member, count)))
                ^^^^^^^^

So there's an addition of three numbers, yet you're only checking that
the addition of two of them doesn't overflow.

Thanks,

Lukas