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;
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
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
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
linux-stable-mirror@lists.linaro.org