From: Lukas Wunner <lukas@wunner.de>
To: Thorsten Blum <thorsten.blum@linux.dev>
Cc: David Howells <dhowells@redhat.com>,
Ignat Korchagin <ignat@cloudflare.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] crypto: asymmetric_keys - simplify asymmetric_key_hex_to_key_id
Date: Sun, 12 Oct 2025 14:10:38 +0200 [thread overview]
Message-ID: <aOuavtSpoNLWHoMS@wunner.de> (raw)
In-Reply-To: <20251007185220.234611-3-thorsten.blum@linux.dev>
On Tue, Oct 07, 2025 at 08:52:21PM +0200, Thorsten Blum wrote:
> Use struct_size() to calculate the number of bytes to allocate for the
> asymmetric key id.
Why? To what end? To guard against an overflow?
I've gone through the callers of asymmetric_key_hex_to_key_id() and
it seems they all limit the length of the keyid. Guarding against
an overflow in asymmetric_key_hex_to_key_id() could thus only be
justified as a defense-in-depth measure, but I doubt that's worth it.
Callers I've found:
- keyctl_keyring_search() [security/keys/keyctl.c]
keyring_search()
type->match_preparse() == asymmetric_key_match_preparse()
asymmetric_key_hex_to_key_id()
Here the size of the key id is constrained to 4096 bytes
(KEY_MAX_DESC_SIZE) by keyctl_keyring_search().
- request_key() [security/keys/keyctl.c]
request_key_and_link()
type->match_preparse() == asymmetric_key_match_preparse()
asymmetric_key_hex_to_key_id()
Same here.
- asymmetric_verify() [security/integrity/digsig_asymmetric.c]
request_asymmetric_key()
find_asymmetric_key()
keyring_search()
type->match_preparse() == asymmetric_key_match_preparse()
asymmetric_key_hex_to_key_id()
Here the size of the key id is a 32-bit integer.
- pkcs7_validate_trust_one() [crypto/asymmetric_keys/pkcs7_trust.c]
find_asymmetric_key()
keyring_search()
type->match_preparse() == asymmetric_key_match_preparse()
asymmetric_key_hex_to_key_id()
Here the key id in hexadecimal is constructed from its binary form,
asymmetric_key_hex_to_key_id() then converts that back. Naturally
the back conversion shouldn't overflow.
- restrict_link_by_signature() [crypto/asymmetric_keys/restrict.c]
find_asymmetric_key()
keyring_search()
type->match_preparse() == asymmetric_key_match_preparse()
asymmetric_key_hex_to_key_id()
Same here.
> +++ b/crypto/asymmetric_keys/asymmetric_type.c
> @@ -236,12 +236,11 @@ 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);
This doesn't look more readable to be honest.
> - ret = __asymmetric_key_hex_to_key_id(id, match_id, asciihexlen / 2);
> - if (ret < 0) {
> + if (__asymmetric_key_hex_to_key_id(id, match_id, hexlen) < 0) {
> kfree(match_id);
> return ERR_PTR(-EINVAL);
> }
If anything, return ret instead of removing the ret variable.
The only negative return value of __asymmetric_key_hex_to_key_id()
is -EINVAL, hence that's returned directly here.
Thanks,
Lukas
next prev parent reply other threads:[~2025-10-12 12:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 18:52 [PATCH 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Thorsten Blum
2025-10-07 18:52 ` [PATCH 2/2] crypto: asymmetric_keys - simplify asymmetric_key_hex_to_key_id Thorsten Blum
2025-10-12 12:10 ` Lukas Wunner [this message]
2025-10-12 13:23 ` Thorsten Blum
2025-10-13 7:00 ` Lukas Wunner
2025-10-12 7:38 ` [PATCH 1/2] crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aOuavtSpoNLWHoMS@wunner.de \
--to=lukas@wunner.de \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=ignat@cloudflare.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thorsten.blum@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.