From: sashiko-bot@kernel.org
Cc: "open list:SECURITY SUBSYSTEM" <linux-security-module@vger.kernel.org>
Subject: Re: [RFC PATCH 3/8] KEYS: Reject @desclen values over U16_MAX in key_alloc()
Date: Mon, 19 Oct 2026 15:49:26 +0000 [thread overview]
Message-ID: <sashiko-outbox-177790@kernel.org> (raw)
In-Reply-To: <20261019142516.300040-4-jarkko@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] KEYS: desc_len truncation in __key_create_or_update() before key_alloc()
--
commit e49d7d031ada6f60dccb5c6e74d1e66145a0c3d4
Author: Jarkko Sakkinen <jarkko@kernel.org>
KEYS: Reject @desclen values over U16_MAX in key_alloc()
This commit adds a bounds check in key_alloc() to reject key descriptions
longer than U16_MAX with -EINVAL, preventing truncation when storing the
length in the 16-bit desc_len field of struct keyring_index_key.
> diff --git a/security/keys/key.c b/security/keys/key.c
> index b34a64d81d47a..a0f083339da8d 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -245,6 +245,8 @@ struct key *key_alloc(struct key_type *type, const char *desc,
> }
>
> desclen = strlen(desc);
> + if (desclen > U16_MAX)
> + goto error;
> quotalen = desclen + 1 + type->def_datalen;
>
> /* get hold of the key tracking for this user */
[Severity: High]
Does __key_create_or_update() also need to validate the description length
before assigning index_key.desc_len?
In security/keys/key.c, __key_create_or_update() assigns strlen() to the
16-bit index_key.desc_len field and passes it into __key_link_begin() and
find_key_to_update() before key_alloc() is called:
security/keys/key.c:__key_create_or_update() {
...
index_key.desc_len = strlen(index_key.description);
key_set_index_key(&index_key);
ret = __key_link_lock(keyring, &index_key);
if (ret < 0) {
key_ref = ERR_PTR(ret);
goto error_free_prep;
}
ret = __key_link_begin(keyring, &index_key, &edit);
if (ret < 0) {
key_ref = ERR_PTR(ret);
goto error_link_end;
}
...
if (allow_update) {
if (index_key.type->update) {
key_ref = find_key_to_update(keyring, &index_key);
if (key_ref)
goto found_matching_key;
}
}
key = key_alloc(index_key.type, index_key.description,
cred->fsuid, cred->fsgid, cred, perm, flags, NULL);
}
Although add_key() limits user-supplied _description strings to
KEY_MAX_DESC_SIZE, _description can be NULL when index_key.type->preparse
generates prep.description from the payload. For example, in
crypto/asymmetric_keys/x509_public_key.c, x509_key_preparse() constructs
prep->description from the X.509 certificate subject and hex-encoded
serial or skid:
desc = kmalloc(sulen + 2 + srlen * 2 + 1, GFP_KERNEL);
if (!desc)
return -ENOMEM;
p = memcpy(desc, cert->subject, sulen);
p += sulen;
*p++ = ':';
*p++ = ' ';
p = bin2hex(p, q, srlen);
*p = 0;
Since the payload can be up to almost 1MB, strlen(index_key.description)
can exceed U16_MAX.
If strlen(index_key.description) is a multiple of 65536 (or 0),
index_key.desc_len truncates to 0 and triggers BUG_ON(index_key->desc_len == 0)
in __key_link_begin() in security/keys/keyring.c before key_alloc() is
reached.
If strlen(index_key.description) > U16_MAX is not a multiple of 65536,
index_key.desc_len truncates to strlen % 65536. Because
keyring_compare_object() in security/keys/keyring.c only compares
index_key->desc_len bytes:
return key->index_key.type == index_key->type &&
key->index_key.domain_tag == index_key->domain_tag &&
key->index_key.desc_len == index_key->desc_len &&
memcmp(key->index_key.description, index_key->description,
index_key->desc_len) == 0;
find_key_to_update() can match an existing key with a shorter description
sharing that prefix and update the wrong key via goto found_matching_key,
bypassing key_alloc() altogether (or fail with -EEXIST instead of -EINVAL).
In addition, keyring_search() in security/keys/keyring.c, as well as
request_key_and_link() and request_key_rcu() in security/keys/request_key.c,
also assign strlen(description) directly to .index_key.desc_len without
bounds checking.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261019142516.300040-1-jarkko@kernel.org?part=3
next prev parent reply other threads:[~2026-10-19 15:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 14:25 [RFC PATCH 0/8] KEYS: rhashtable bug fixes Jarkko Sakkinen
2026-10-19 14:25 ` [RFC PATCH 1/8] KEYS: Change the type of key->quotalen to unsigned int Jarkko Sakkinen
2026-10-19 15:37 ` sashiko-bot
2026-10-19 14:25 ` [RFC PATCH 2/8] KEYS: Change the type of key->datalen " Jarkko Sakkinen
2026-10-19 15:33 ` David Howells
2026-10-19 16:31 ` Jarkko Sakkinen
2026-10-19 15:41 ` sashiko-bot
2026-10-19 14:25 ` [RFC PATCH 3/8] KEYS: Reject @desclen values over U16_MAX in key_alloc() Jarkko Sakkinen
2026-10-19 15:35 ` David Howells
2026-10-19 16:32 ` Jarkko Sakkinen
2026-10-19 15:49 ` sashiko-bot [this message]
2026-10-19 14:25 ` [RFC PATCH 4/8] KEYS: Prevent overflow of user->qnkeys " Jarkko Sakkinen
2026-10-19 16:02 ` sashiko-bot
2026-10-19 14:25 ` [RFC PATCH 5/8] KEYS: Prevent overflow of quota " Jarkko Sakkinen
2026-10-19 15:40 ` David Howells
2026-10-19 16:33 ` Jarkko Sakkinen
2026-10-19 16:16 ` sashiko-bot
2026-10-19 14:25 ` [RFC PATCH 6/8] KEYS: Prevent overflow of user->qnbytes " Jarkko Sakkinen
2026-10-19 15:41 ` David Howells
2026-10-19 16:34 ` Jarkko Sakkinen
2026-10-19 16:18 ` sashiko-bot
2026-10-19 14:25 ` [RFC PATCH 7/8] KEYS: Reject @datalen values over INT_MAX Jarkko Sakkinen
2026-10-19 15:43 ` David Howells
2026-10-19 16:35 ` Jarkko Sakkinen
2026-10-19 16:21 ` sashiko-bot
2026-10-19 14:25 ` [RFC PATCH 8/8] KEYS: Verify the key identity in __keyctl_unlink Jarkko Sakkinen
2026-10-19 15:55 ` David Howells
2026-10-19 16:37 ` Jarkko Sakkinen
2026-10-19 16:23 ` sashiko-bot
2026-10-19 14:33 ` [RFC PATCH 0/8] KEYS: rhashtable bug fixes Jarkko Sakkinen
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=sashiko-outbox-177790@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sashiko-reviews@lists.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.