[PATCH v4 0/3] KEYS: rhashtable bug fixes

[PATCH v4 0/3] KEYS: rhashtable bug fixes

[Jarkko Sakkinen]

My patch set that migrates assoc_array to rhashtable had some LLM
scavegend bug fixes. Unfortunately most them where either plain wrong or
not in the right scope. The bug fixes in this patch set are by human
labour constructed fully but they are derived from what I got out of the
original LLM source. Thus, they are tagged as LLM assisted.

Changelog
=========

- v4: Based on Eric's feedback did inventory of sites where description
  can go unchecked and fixed 2/3 accordingly.
- v4: Addressed Eric's remark about cifs_dbg() statements that need to
  be changed in 1/3.
- v3: https://lore.kernel.org/keyrings/20261020013903.1244157-1-jarkko@kernel.org/
- v3: Added couple of example, one of my own and other derived from
  David's snippet.
- v3: Removed bunch of unnecessary INT_MAX checks (Eric).
- v2: https://lore.kernel.org/keyrings/20261019181732.449591-1-jarkko@kernel.org/
- v2: Addressed issues pointed out by David.
- v1: https://lore.kernel.org/keyrings/20261019142516.300040-1-jarkko@kernel.org/

Jarkko Sakkinen (3):
  KEYS: Expand key->{datalen,quotalen} to unsigned int
  KEYS: Reject descriptions larger than KEY_MAX_DESC_SIZE
  KEYS: Verify the key identity in __key_unlink_begin

 fs/smb/client/cifsacl.c     |  6 +++---
 include/linux/key.h         |  7 +++++--
 security/keys/key.c         | 10 +++++++++-
 security/keys/keyctl.c      |  2 --
 security/keys/keyring.c     | 13 ++++++++++++-
 security/keys/request_key.c | 14 ++++++++++++--
 6 files changed, 41 insertions(+), 11 deletions(-)

--
2.47.3

[PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[Jarkko Sakkinen]

In key_alloc() and key_payload_reserve(), key->quotalen and key->datalen
can receive values larger than USHRT_MAX.

Example:

  keyctl new_session >/dev/null
  owner=$(keyctl newring owner @s)
  keeper=$(keyctl newring keeper @s)

  for ((i=0; i<16384; i++)); do
      key=$(keyctl add user "k$i" x "$keeper")
      keyctl link "$key" "$owner"
  done

  awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users
  keyctl clear "$owner"
  awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users

Because key->datalen wraps around 65535, the quota refunded upon clearing
is truncated, causing quota bytes to leak in /proc/key-users.

Change the types of key->datalen and key->quotalen from unsigned short to
unsigned int so that they can carry the full payload length without
truncation.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 fs/smb/client/cifsacl.c | 6 +++---
 include/linux/key.h     | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/smb/client/cifsacl.c b/fs/smb/client/cifsacl.c
index c5e47a835f99..de2acc7234be 100644
--- a/fs/smb/client/cifsacl.c
+++ b/fs/smb/client/cifsacl.c
@@ -385,7 +385,7 @@ id_to_sid(unsigned int cid, uint sidtype, struct smb_sid *ssid)
 		goto out_revert_creds;
 	} else if (sidkey->datalen < CIFS_SID_BASE_SIZE) {
 		rc = smb_EIO1(smb_eio_trace_malformed_sid_key, sidkey->datalen);
-		cifs_dbg(FYI, "%s: Downcall contained malformed key (datalen=%hu)\n",
+		cifs_dbg(FYI, "%s: Downcall contained malformed key (datalen=%u)\n",
 			 __func__, sidkey->datalen);
 		goto invalidate_key;
 	}
@@ -403,7 +403,7 @@ id_to_sid(unsigned int cid, uint sidtype, struct smb_sid *ssid)
 	if (ksid_size > sidkey->datalen) {
 		rc = smb_EIO2(smb_eio_trace_malformed_ksid_key,
 			      ksid_size, sidkey->datalen);
-		cifs_dbg(FYI, "%s: Downcall contained malformed key (datalen=%hu, ksid_size=%u)\n",
+		cifs_dbg(FYI, "%s: Downcall contained malformed key (datalen=%u, ksid_size=%u)\n",
 			 __func__, sidkey->datalen, ksid_size);
 		goto invalidate_key;
 	}
@@ -498,7 +498,7 @@ sid_to_id(struct cifs_sb_info *cifs_sb, struct smb_sid *psid,
 	 */
 	BUILD_BUG_ON(sizeof(uid_t) != sizeof(gid_t));
 	if (sidkey->datalen != sizeof(uid_t)) {
-		cifs_dbg(FYI, "%s: Downcall contained malformed key (datalen=%hu)\n",
+		cifs_dbg(FYI, "%s: Downcall contained malformed key (datalen=%u)\n",
 			 __func__, sidkey->datalen);
 		key_invalidate(sidkey);
 		goto out_key_put;
diff --git a/include/linux/key.h b/include/linux/key.h
index e40b5267658f..26139c3adf62 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -216,8 +216,8 @@ struct key {
 	kuid_t			uid;
 	kgid_t			gid;
 	key_perm_t		perm;		/* access permissions */
-	unsigned short		quotalen;	/* length added to quota */
-	unsigned short		datalen;	/* payload data length
+	unsigned int		quotalen;	/* length added to quota */
+	unsigned int		datalen;	/* payload data length
 						 * - may not match RCU dereferenced payload
 						 * - payload should contain own length
 						 */
-- 
2.47.3

Re: [PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[sashiko-bot]

> In key_alloc() and key_payload_reserve(), key->quotalen and key->datalen
> can receive values larger than USHRT_MAX.
> 
> Example:
> 
>   keyctl new_session >/dev/null
>   owner=$(keyctl newring owner @s)
>   keeper=$(keyctl newring keeper @s)
> 
>   for ((i=0; i<16384; i++)); do
>       key=$(keyctl add user "k$i" x "$keeper")
>       keyctl link "$key" "$owner"
>   done
> 
>   awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users
>   keyctl clear "$owner"
>   awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users
> 
> Because key->datalen wraps around 65535, the quota refunded upon clearing
> is truncated, causing quota bytes to leak in /proc/key-users.
> 
> Change the types of key->datalen and key->quotalen from unsigned short to
> unsigned int so that they can carry the full payload length without
> truncation.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reviewed-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261020174325.2229448-1-jarkko@kernel.org?part=1

Re: [PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[Jarkko Sakkinen]

On Tue, Oct 20, 2026 at 08:43:19PM +0300, Jarkko Sakkinen wrote:
> In key_alloc() and key_payload_reserve(), key->quotalen and key->datalen
> can receive values larger than USHRT_MAX.
> 
> Example:
> 
>   keyctl new_session >/dev/null
>   owner=$(keyctl newring owner @s)
>   keeper=$(keyctl newring keeper @s)
> 
>   for ((i=0; i<16384; i++)); do
>       key=$(keyctl add user "k$i" x "$keeper")
>       keyctl link "$key" "$owner"
>   done
> 
>   awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users
>   keyctl clear "$owner"
>   awk -v uid="$(id -u):" '$1 == uid {print $NF}' /proc/key-users
> 
> Because key->datalen wraps around 65535, the quota refunded upon clearing
> is truncated, causing quota bytes to leak in /proc/key-users.
> 
> Change the types of key->datalen and key->quotalen from unsigned short to
> unsigned int so that they can carry the full payload length without
> truncation.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reviewed-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

For any kernel patches I've missed all Sashiko reviews so far and have
not taken the feedback into account in anything.

There is two issues:

1. I was not subscribed to linux-security-module. I could be and have
   been but probably when I've changed my list subscriptions at some
   point otherwise, I happened not to be.
2. Even if I was subscribed to linux-security-module, at least I'd
   like to get reviews Cc'd that concern my patches or patches
   sent to me.

Now that Eric pointed out Sashiko review I was able to look up this
via web browser:

https://lore.kernel.org/linux-security-module/20261020174325.2229448-1-jarkko@kernel.org/T/#mccc5900222fdad9d790be343fcec2a32540ed2fb

This is somewhat inconvenient though that it responds like that, and
not to the review thread.

Not actually sure how do you write a Sieve filter that automates
relevant-to-me Sashiko emails going into some specific folder but
I'm sure that is somehow possible. I guess I'll start by subscribing
to linux-security-module.

Br, Jarkko

Re: [PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[Jarkko Sakkinen]

On Tue, Oct 20, 2026 at 11:49:46PM +0300, Jarkko Sakkinen wrote:
> Now that Eric pointed out Sashiko review I was able to look up this
> via web browser:
> 
> https://lore.kernel.org/linux-security-module/20261020174325.2229448-1-jarkko@kernel.org/T/#mccc5900222fdad9d790be343fcec2a32540ed2fb
> 
> This is somewhat inconvenient though that it responds like that, and
> not to the review thread.
> 
> Not actually sure how do you write a Sieve filter that automates
> relevant-to-me Sashiko emails going into some specific folder but
> I'm sure that is somehow possible. I guess I'll start by subscribing
> to linux-security-module.

I.e. nothing against Sashiko per se. It is probably useful but it has
configuration that is worse than eg syzkaller has. I will adapt to that
but this still the case. It is easier to adapt now that it finally
unmasked itself :-)

Br, Jarkko

Re: [PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[Eric Biggers]

On Tue, Oct 20, 2026 at 11:49:41PM +0300, Jarkko Sakkinen wrote:
> For any kernel patches I've missed all Sashiko reviews so far and have
> not taken the feedback into account in anything.
> 
> There is two issues:
> 
> 1. I was not subscribed to linux-security-module. I could be and have
>    been but probably when I've changed my list subscriptions at some
>    point otherwise, I happened not to be.
> 2. Even if I was subscribed to linux-security-module, at least I'd
>    like to get reviews Cc'd that concern my patches or patches
>    sent to me.
> 
> Now that Eric pointed out Sashiko review I was able to look up this
> via web browser:
> 
> https://lore.kernel.org/linux-security-module/20261020174325.2229448-1-jarkko@kernel.org/T/#mccc5900222fdad9d790be343fcec2a32540ed2fb
> 
> This is somewhat inconvenient though that it responds like that, and
> not to the review thread.
> 
> Not actually sure how do you write a Sieve filter that automates
> relevant-to-me Sashiko emails going into some specific folder but
> I'm sure that is somehow possible. I guess I'll start by subscribing
> to linux-security-module.

Well, the keyrings mailing list isn't currently opted into Sashiko
monitoring or emails.  linux-security-modules is opted in, but it's set
to have the Sashiko emails go to only that list.  See
https://github.com/sashiko-dev/sashiko/blob/main/projects/linux/mailing_lists.toml

    ["linux-security-module@vger.kernel.org"]
    reply_to = ["list"]
    positive_review = "all"

(Sashiko defaults to no email, because unfortunately there hasn't yet
been consensus in the kernel community to enable it everywhere yet.)

keyrings could be opted in by opening a GitHub pull request that edits
that file.  Let me know if you want me to do it.

My preference is what I set the fscrypt and fsverity lists too: enable
monitoring of the list and emails of issues found to everyone (but not
the noisy positive reviews, i.e. "It looks great!"):

    ["linux-fscrypt@vger.kernel.org"]
    reply_to = ["author", "list", "recipients"]

So for keyrings I suggest we add:

    ["keyrings@vger.kernel.org"]
    reply_to = ["author", "list", "recipients"]

Do you agree with that?

- Eric

Re: [PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[Jarkko Sakkinen]

On Tue, Oct 20, 2026 at 09:43:35PM +0000, Eric Biggers wrote:
> On Tue, Oct 20, 2026 at 11:49:41PM +0300, Jarkko Sakkinen wrote:
> > For any kernel patches I've missed all Sashiko reviews so far and have
> > not taken the feedback into account in anything.
> > 
> > There is two issues:
> > 
> > 1. I was not subscribed to linux-security-module. I could be and have
> >    been but probably when I've changed my list subscriptions at some
> >    point otherwise, I happened not to be.
> > 2. Even if I was subscribed to linux-security-module, at least I'd
> >    like to get reviews Cc'd that concern my patches or patches
> >    sent to me.
> > 
> > Now that Eric pointed out Sashiko review I was able to look up this
> > via web browser:
> > 
> > https://lore.kernel.org/linux-security-module/20261020174325.2229448-1-jarkko@kernel.org/T/#mccc5900222fdad9d790be343fcec2a32540ed2fb
> > 
> > This is somewhat inconvenient though that it responds like that, and
> > not to the review thread.
> > 
> > Not actually sure how do you write a Sieve filter that automates
> > relevant-to-me Sashiko emails going into some specific folder but
> > I'm sure that is somehow possible. I guess I'll start by subscribing
> > to linux-security-module.
> 
> Well, the keyrings mailing list isn't currently opted into Sashiko
> monitoring or emails.  linux-security-modules is opted in, but it's set
> to have the Sashiko emails go to only that list.  See
> https://github.com/sashiko-dev/sashiko/blob/main/projects/linux/mailing_lists.toml
> 
>     ["linux-security-module@vger.kernel.org"]
>     reply_to = ["list"]
>     positive_review = "all"
> 
> (Sashiko defaults to no email, because unfortunately there hasn't yet
> been consensus in the kernel community to enable it everywhere yet.)
> 
> keyrings could be opted in by opening a GitHub pull request that edits
> that file.  Let me know if you want me to do it.
> 
> My preference is what I set the fscrypt and fsverity lists too: enable
> monitoring of the list and emails of issues found to everyone (but not
> the noisy positive reviews, i.e. "It looks great!"):
> 
>     ["linux-fscrypt@vger.kernel.org"]
>     reply_to = ["author", "list", "recipients"]
> 
> So for keyrings I suggest we add:
> 
>     ["keyrings@vger.kernel.org"]
>     reply_to = ["author", "list", "recipients"]
> 
> Do you agree with that?

Yeah, that would help, thanks :-)

> 
> - Eric

Br, Jarkko

Re: [PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[Eric Biggers]

On Wed, Oct 21, 2026 at 01:01:47AM +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 20, 2026 at 09:43:35PM +0000, Eric Biggers wrote:
> > On Tue, Oct 20, 2026 at 11:49:41PM +0300, Jarkko Sakkinen wrote:
> > > For any kernel patches I've missed all Sashiko reviews so far and have
> > > not taken the feedback into account in anything.
> > > 
> > > There is two issues:
> > > 
> > > 1. I was not subscribed to linux-security-module. I could be and have
> > >    been but probably when I've changed my list subscriptions at some
> > >    point otherwise, I happened not to be.
> > > 2. Even if I was subscribed to linux-security-module, at least I'd
> > >    like to get reviews Cc'd that concern my patches or patches
> > >    sent to me.
> > > 
> > > Now that Eric pointed out Sashiko review I was able to look up this
> > > via web browser:
> > > 
> > > https://lore.kernel.org/linux-security-module/20261020174325.2229448-1-jarkko@kernel.org/T/#mccc5900222fdad9d790be343fcec2a32540ed2fb
> > > 
> > > This is somewhat inconvenient though that it responds like that, and
> > > not to the review thread.
> > > 
> > > Not actually sure how do you write a Sieve filter that automates
> > > relevant-to-me Sashiko emails going into some specific folder but
> > > I'm sure that is somehow possible. I guess I'll start by subscribing
> > > to linux-security-module.
> > 
> > Well, the keyrings mailing list isn't currently opted into Sashiko
> > monitoring or emails.  linux-security-modules is opted in, but it's set
> > to have the Sashiko emails go to only that list.  See
> > https://github.com/sashiko-dev/sashiko/blob/main/projects/linux/mailing_lists.toml
> > 
> >     ["linux-security-module@vger.kernel.org"]
> >     reply_to = ["list"]
> >     positive_review = "all"
> > 
> > (Sashiko defaults to no email, because unfortunately there hasn't yet
> > been consensus in the kernel community to enable it everywhere yet.)
> > 
> > keyrings could be opted in by opening a GitHub pull request that edits
> > that file.  Let me know if you want me to do it.
> > 
> > My preference is what I set the fscrypt and fsverity lists too: enable
> > monitoring of the list and emails of issues found to everyone (but not
> > the noisy positive reviews, i.e. "It looks great!"):
> > 
> >     ["linux-fscrypt@vger.kernel.org"]
> >     reply_to = ["author", "list", "recipients"]
> > 
> > So for keyrings I suggest we add:
> > 
> >     ["keyrings@vger.kernel.org"]
> >     reply_to = ["author", "list", "recipients"]
> > 
> > Do you agree with that?
> 
> Yeah, that would help, thanks :-)

FYI, it's merged now: https://github.com/sashiko-dev/sashiko/pull/719

- Eric

Re: [PATCH v4 1/3] KEYS: Expand key->{datalen,quotalen} to unsigned int

[Jarkko Sakkinen]

On Wed, Oct 21, 2026 at 10:03:21AM -0700, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 01:01:47AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Oct 20, 2026 at 09:43:35PM +0000, Eric Biggers wrote:
> > > On Tue, Oct 20, 2026 at 11:49:41PM +0300, Jarkko Sakkinen wrote:
> > > > For any kernel patches I've missed all Sashiko reviews so far and have
> > > > not taken the feedback into account in anything.
> > > > 
> > > > There is two issues:
> > > > 
> > > > 1. I was not subscribed to linux-security-module. I could be and have
> > > >    been but probably when I've changed my list subscriptions at some
> > > >    point otherwise, I happened not to be.
> > > > 2. Even if I was subscribed to linux-security-module, at least I'd
> > > >    like to get reviews Cc'd that concern my patches or patches
> > > >    sent to me.
> > > > 
> > > > Now that Eric pointed out Sashiko review I was able to look up this
> > > > via web browser:
> > > > 
> > > > https://lore.kernel.org/linux-security-module/20261020174325.2229448-1-jarkko@kernel.org/T/#mccc5900222fdad9d790be343fcec2a32540ed2fb
> > > > 
> > > > This is somewhat inconvenient though that it responds like that, and
> > > > not to the review thread.
> > > > 
> > > > Not actually sure how do you write a Sieve filter that automates
> > > > relevant-to-me Sashiko emails going into some specific folder but
> > > > I'm sure that is somehow possible. I guess I'll start by subscribing
> > > > to linux-security-module.
> > > 
> > > Well, the keyrings mailing list isn't currently opted into Sashiko
> > > monitoring or emails.  linux-security-modules is opted in, but it's set
> > > to have the Sashiko emails go to only that list.  See
> > > https://github.com/sashiko-dev/sashiko/blob/main/projects/linux/mailing_lists.toml
> > > 
> > >     ["linux-security-module@vger.kernel.org"]
> > >     reply_to = ["list"]
> > >     positive_review = "all"
> > > 
> > > (Sashiko defaults to no email, because unfortunately there hasn't yet
> > > been consensus in the kernel community to enable it everywhere yet.)
> > > 
> > > keyrings could be opted in by opening a GitHub pull request that edits
> > > that file.  Let me know if you want me to do it.
> > > 
> > > My preference is what I set the fscrypt and fsverity lists too: enable
> > > monitoring of the list and emails of issues found to everyone (but not
> > > the noisy positive reviews, i.e. "It looks great!"):
> > > 
> > >     ["linux-fscrypt@vger.kernel.org"]
> > >     reply_to = ["author", "list", "recipients"]
> > > 
> > > So for keyrings I suggest we add:
> > > 
> > >     ["keyrings@vger.kernel.org"]
> > >     reply_to = ["author", "list", "recipients"]
> > > 
> > > Do you agree with that?
> > 
> > Yeah, that would help, thanks :-)
> 
> FYI, it's merged now: https://github.com/sashiko-dev/sashiko/pull/719

Thanks, and about wrapper. I tried it and it does not play out 
in practice so no changes to the patch set from my side unless
there is something that needs to be still fixed.

> 
> - Eric

Br, Jarkko

[PATCH v4 2/3] KEYS: Reject descriptions larger than KEY_MAX_DESC_SIZE

[Jarkko Sakkinen]

KEY_MAX_DESC_SIZE includes the trailing NULL character. Descriptions
generated from payloads and in-kernel paths bypass the userspace limit.

Reject descriptions at or above KEY_MAX_DESC_SIZE with -EINVAL at the
following sites:

- key_alloc(): before quota calculation
- __key_create_or_update(): before key_set_index_key()
- keyring_search(): before match_preparse
- request_key_and_link(): before match_preparse
- request_key_rcu(): before check_cached_key()

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: f771fde82051 ("keys: Simplify key description management")
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 include/linux/key.h         |  3 +++
 security/keys/key.c         | 10 +++++++++-
 security/keys/keyctl.c      |  2 --
 security/keys/keyring.c     |  7 ++++++-
 security/keys/request_key.c | 14 ++++++++++++--
 5 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/include/linux/key.h b/include/linux/key.h
index 26139c3adf62..3b8af14fb323 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -37,6 +37,9 @@ struct net;
 
 #undef KEY_DEBUGGING
 
+/* Maximum length of a key description, including the trailing NUL */
+#define KEY_MAX_DESC_SIZE 4096
+
 #define KEY_POS_VIEW	0x01000000	/* possessor can view a key's attributes */
 #define KEY_POS_READ	0x02000000	/* possessor can read key payload / view keyring */
 #define KEY_POS_WRITE	0x04000000	/* possessor can update key payload / add link to keyring */
diff --git a/security/keys/key.c b/security/keys/key.c
index 6ebb8691551f..e88548f1a704 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 >= KEY_MAX_DESC_SIZE)
+		goto error;
 	quotalen = desclen + 1 + type->def_datalen;
 
 	/* get hold of the key tracking for this user */
@@ -829,6 +831,7 @@ static key_ref_t __key_create_or_update(key_ref_t keyring_ref,
 	key_ref_t key_ref;
 	int ret;
 	struct key_restriction *restrict_link = NULL;
+	size_t desclen;
 
 	/* look up the key type to see if it's one of the registered kernel
 	 * types */
@@ -869,7 +872,12 @@ static key_ref_t __key_create_or_update(key_ref_t keyring_ref,
 		if (!index_key.description)
 			goto error_free_prep;
 	}
-	index_key.desc_len = strlen(index_key.description);
+	desclen = strlen(index_key.description);
+	if (desclen >= KEY_MAX_DESC_SIZE) {
+		key_ref = ERR_PTR(-EINVAL);
+		goto error_free_prep;
+	}
+	index_key.desc_len = desclen;
 	key_set_index_key(&index_key);
 
 	ret = __key_link_lock(keyring, &index_key);
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 36ffba0ebba6..d6b10fd67627 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -24,8 +24,6 @@
 #include <keys/request_key_auth-type.h>
 #include "internal.h"
 
-#define KEY_MAX_DESC_SIZE 4096
-
 static const unsigned char keyrings_capabilities[2] = {
 	[0] = (KEYCTL_CAPS0_CAPABILITIES |
 	       (IS_ENABLED(CONFIG_PERSISTENT_KEYRINGS)	? KEYCTL_CAPS0_PERSISTENT_KEYRINGS : 0) |
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 7143f3079d20..2c54f7f84c55 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -957,7 +957,6 @@ key_ref_t keyring_search(key_ref_t keyring,
 	struct keyring_search_context ctx = {
 		.index_key.type		= type,
 		.index_key.description	= description,
-		.index_key.desc_len	= strlen(description),
 		.cred			= current_cred(),
 		.match_data.cmp		= key_default_cmp,
 		.match_data.raw_data	= description,
@@ -965,8 +964,14 @@ key_ref_t keyring_search(key_ref_t keyring,
 		.flags			= KEYRING_SEARCH_DO_STATE_CHECK,
 	};
 	key_ref_t key;
+	size_t desclen;
 	int ret;
 
+	desclen = strlen(description);
+	if (desclen >= KEY_MAX_DESC_SIZE)
+		return ERR_PTR(-EINVAL);
+	ctx.index_key.desc_len = desclen;
+
 	if (recurse)
 		ctx.flags |= KEYRING_SEARCH_RECURSE;
 	if (type->match_preparse) {
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index fa2bb9f2f538..ef00c2b08fe0 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -584,7 +584,6 @@ struct key *request_key_and_link(struct key_type *type,
 		.index_key.type		= type,
 		.index_key.domain_tag	= domain_tag,
 		.index_key.description	= description,
-		.index_key.desc_len	= strlen(description),
 		.cred			= current_cred(),
 		.match_data.cmp		= key_default_cmp,
 		.match_data.raw_data	= description,
@@ -595,8 +594,14 @@ struct key *request_key_and_link(struct key_type *type,
 	};
 	struct key *key;
 	key_ref_t key_ref;
+	size_t desclen;
 	int ret;
 
+	desclen = strlen(description);
+	if (desclen >= KEY_MAX_DESC_SIZE)
+		return ERR_PTR(-EINVAL);
+	ctx.index_key.desc_len = desclen;
+
 	kenter("%s,%s,%p,%zu,%p,%p,%lx",
 	       ctx.index_key.type->name, ctx.index_key.description,
 	       callout_info, callout_len, aux, dest_keyring, flags);
@@ -787,7 +792,6 @@ struct key *request_key_rcu(struct key_type *type,
 		.index_key.type		= type,
 		.index_key.domain_tag	= domain_tag,
 		.index_key.description	= description,
-		.index_key.desc_len	= strlen(description),
 		.cred			= current_cred(),
 		.match_data.cmp		= key_default_cmp,
 		.match_data.raw_data	= description,
@@ -797,6 +801,12 @@ struct key *request_key_rcu(struct key_type *type,
 	};
 	struct key *key;
 	key_ref_t key_ref;
+	size_t desclen;
+
+	desclen = strlen(description);
+	if (desclen >= KEY_MAX_DESC_SIZE)
+		return ERR_PTR(-EINVAL);
+	ctx.index_key.desc_len = desclen;
 
 	kenter("%s,%s", type->name, description);
 
-- 
2.47.3

Re: [PATCH v4 2/3] KEYS: Reject descriptions larger than KEY_MAX_DESC_SIZE

[sashiko-bot]

> KEY_MAX_DESC_SIZE includes the trailing NULL character. Descriptions
> generated from payloads and in-kernel paths bypass the userspace limit.
> 
> Reject descriptions at or above KEY_MAX_DESC_SIZE with -EINVAL at the
> following sites:
> 
> - key_alloc(): before quota calculation
> - __key_create_or_update(): before key_set_index_key()
> - keyring_search(): before match_preparse
> - request_key_and_link(): before match_preparse
> - request_key_rcu(): before check_cached_key()
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: f771fde82051 ("keys: Simplify key description management")
> Reviewed-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261020174325.2229448-1-jarkko@kernel.org?part=2

Re: [PATCH v4 2/3] KEYS: Reject descriptions larger than KEY_MAX_DESC_SIZE

[Jarkko Sakkinen]

On Tue, Oct 20, 2026 at 08:43:20PM +0300, Jarkko Sakkinen wrote:

There is only case in key_alloc() where index_key.desc_len is not set:

	desclen = strlen(desc);
	if (desclen >= KEY_MAX_DESC_SIZE)
		goto error;


Other sites match to:

	static int keyring_index_key_set_desc(void *desc, int desclen)
	{
		desclen = strlen(index_key.description);
		if (desclen >= KEY_MAX_DESC_SIZE) {
			return -EINVAL;
		}
		index_key->desc_len = desclen;
	}	

Given how long setter for index key's has been broken at some many sites
and the bug has been buried for so many years, I don't see any good
reason not to make the operation explicit with a wrapper.

In this the size of this patch would also shrink as a result.

Br, Jarkko
 

Re: [PATCH v4 2/3] KEYS: Reject descriptions larger than KEY_MAX_DESC_SIZE

[Jarkko Sakkinen]

On Wed, Oct 21, 2026 at 12:16:23AM +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 20, 2026 at 08:43:20PM +0300, Jarkko Sakkinen wrote:
> 
> There is only case in key_alloc() where index_key.desc_len is not set:
> 
> 	desclen = strlen(desc);
> 	if (desclen >= KEY_MAX_DESC_SIZE)
> 		goto error;
> 
> 
> Other sites match to:
> 
> 	static int keyring_index_key_set_desc(void *desc, int desclen)
 	static inline int keyring_index_key_set_desc(struct keyring_index_key *index_key, void *desc, int desclen)
> 	{
> 		desclen = strlen(index_key.description);
> 		if (desclen >= KEY_MAX_DESC_SIZE) {
> 			return -EINVAL;
> 		}
> 		index_key->desc_len = desclen;

		return 0;
> 	}	


Br, Jarkko

[PATCH v4 3/3] KEYS: Verify the key identity in __key_unlink_begin

[Jarkko Sakkinen]

When two keys have identical type and description, linking the second key
replaces the first in a keyring. However, attempting to unlink the first
key (no longer in the keyring) unlinks the second key.

This happens because __key_unlink_begin() calls assoc_array_delete() with
&key->index_key, matching only on type and description rather than the
key's identity.

Example:

  keyctl new_session >/dev/null
  keyctl newring ring_a @s
  keyctl newring ring_b @s
  A=$(keyctl add user A ss %:ring_a)
  B=$(keyctl add user A qq %:ring_b)
  keyctl newring R @s
  keyctl link $A %:R
  keyctl link $B %:R
  keyctl unlink $A %:R
  keyctl show

Verify the key identity before unlinking, and return -ENOENT on mismatch,
instead of unlinking the key with the wrong identity.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 security/keys/keyring.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index 2c54f7f84c55..5281da9d5bf7 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -1506,9 +1506,15 @@ static int __key_unlink_begin(struct key *keyring, struct key *key,
 			      struct assoc_array_edit **_edit)
 {
 	struct assoc_array_edit *edit;
+	const void *object;
 
 	BUG_ON(*_edit != NULL);
 
+	object = assoc_array_find(&keyring->keys, &keyring_assoc_array_ops,
+				  &key->index_key);
+	if (!object || keyring_ptr_to_key(object) != key)
+		return -ENOENT;
+
 	edit = assoc_array_delete(&keyring->keys, &keyring_assoc_array_ops,
 				  &key->index_key);
 	if (IS_ERR(edit))
-- 
2.47.3

Re: [PATCH v4 3/3] KEYS: Verify the key identity in __key_unlink_begin

[sashiko-bot]

> When two keys have identical type and description, linking the second key
> replaces the first in a keyring. However, attempting to unlink the first
> key (no longer in the keyring) unlinks the second key.
> 
> This happens because __key_unlink_begin() calls assoc_array_delete() with
> &key->index_key, matching only on type and description rather than the
> key's identity.
> 
> Example:
> 
>   keyctl new_session >/dev/null
>   keyctl newring ring_a @s
>   keyctl newring ring_b @s
>   A=$(keyctl add user A ss %:ring_a)
>   B=$(keyctl add user A qq %:ring_b)
>   keyctl newring R @s
>   keyctl link $A %:R
>   keyctl link $B %:R
>   keyctl unlink $A %:R
>   keyctl show
> 
> Verify the key identity before unlinking, and return -ENOENT on mismatch,
> instead of unlinking the key with the wrong identity.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
> Reviewed-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261020174325.2229448-1-jarkko@kernel.org?part=3

Re: [PATCH v4 0/3] KEYS: rhashtable bug fixes

[Jarkko Sakkinen]

On Tue, Oct 20, 2026 at 08:43:18PM +0300, Jarkko Sakkinen wrote:
> My patch set that migrates assoc_array to rhashtable had some LLM
> scavegend bug fixes. Unfortunately most them where either plain wrong or
> not in the right scope. The bug fixes in this patch set are by human
> labour constructed fully but they are derived from what I got out of the
> original LLM source. Thus, they are tagged as LLM assisted.

I guess these are ready to be merged? Eric do you have something for
this revision? I already sent -rc1 pull request i.e., I don't mind
to update it if necessary but otherwise I rather would just apply
these.

Br, Jarkko

Re: [PATCH v4 0/3] KEYS: rhashtable bug fixes

[Eric Biggers]

On Wed, Oct 21, 2026 at 10:33:20PM +0300, Jarkko Sakkinen wrote:
> On Tue, Oct 20, 2026 at 08:43:18PM +0300, Jarkko Sakkinen wrote:
> > My patch set that migrates assoc_array to rhashtable had some LLM
> > scavegend bug fixes. Unfortunately most them where either plain wrong or
> > not in the right scope. The bug fixes in this patch set are by human
> > labour constructed fully but they are derived from what I got out of the
> > original LLM source. Thus, they are tagged as LLM assisted.
> 
> I guess these are ready to be merged? Eric do you have something for
> this revision? I already sent -rc1 pull request i.e., I don't mind
> to update it if necessary but otherwise I rather would just apply
> these.

Looks okay now.

Reviewed-by: Eric Biggers <ebiggers@kernel.org>

- Eric

Re: [PATCH v4 0/3] KEYS: rhashtable bug fixes

[Jarkko Sakkinen]

On Wed, Oct 21, 2026 at 08:03:27PM +0000, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 10:33:20PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Oct 20, 2026 at 08:43:18PM +0300, Jarkko Sakkinen wrote:
> > > My patch set that migrates assoc_array to rhashtable had some LLM
> > > scavegend bug fixes. Unfortunately most them where either plain wrong or
> > > not in the right scope. The bug fixes in this patch set are by human
> > > labour constructed fully but they are derived from what I got out of the
> > > original LLM source. Thus, they are tagged as LLM assisted.
> > 
> > I guess these are ready to be merged? Eric do you have something for
> > this revision? I already sent -rc1 pull request i.e., I don't mind
> > to update it if necessary but otherwise I rather would just apply
> > these.
> 
> Looks okay now.
> 
> Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> 
> - Eric

Awesome, thank you.

Br, Jarkko