[RFC PATCH 0/8] KEYS: rhashtable bug fixes

[RFC PATCH 0/8] 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.

Jarkko Sakkinen (8):
  KEYS: Change the type of key->quotalen to unsigned int
  KEYS: Change the type of key->datalen to unsigned int
  KEYS: Reject @desclen values over U16_MAX in key_alloc()
  KEYS: Prevent overflow of user->qnkeys in key_alloc()
  KEYS: Prevent overflow of quota in key_alloc()
  KEYS: Prevent overflow of user->qnbytes in key_alloc()
  KEYS: Reject @datalen values over INT_MAX
  KEYS: Verify the key identity in __keyctl_unlink

 include/linux/key.h     |  4 ++--
 security/keys/key.c     | 13 ++++++++++++-
 security/keys/keyring.c |  6 ++++++
 3 files changed, 20 insertions(+), 3 deletions(-)

--
2.47.3

[RFC PATCH 1/8] KEYS: Change the type of key->quotalen to unsigned int

[Jarkko Sakkinen]

key_alloc() and key_payload_reserve() set key->quotalen with values,
which can be larger than USHRT_MAX.

Change the type from unsigned short to unsigned int.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 include/linux/key.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/key.h b/include/linux/key.h
index e40b5267658f..6729536a76b2 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -216,7 +216,7 @@ struct key {
 	kuid_t			uid;
 	kgid_t			gid;
 	key_perm_t		perm;		/* access permissions */
-	unsigned short		quotalen;	/* length added to quota */
+	unsigned int		quotalen;	/* length added to quota */
 	unsigned short		datalen;	/* payload data length
 						 * - may not match RCU dereferenced payload
 						 * - payload should contain own length
-- 
2.47.3

Re: [RFC PATCH 1/8] KEYS: Change the type of key->quotalen to unsigned int

[sashiko-bot]

> key_alloc() and key_payload_reserve() set key->quotalen with values,
> which can be larger than USHRT_MAX.
> 
> Change the type from unsigned short to unsigned int.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

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

[RFC PATCH 2/8] KEYS: Change the type of key->datalen to unsigned int

[Jarkko Sakkinen]

key_alloc() and key_payload_reserve() set key->datalen with values,
which can be larger than USHRT_MAX.

Change the type from unsigned short to unsigned int.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 include/linux/key.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/key.h b/include/linux/key.h
index 6729536a76b2..26139c3adf62 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -217,7 +217,7 @@ struct key {
 	kgid_t			gid;
 	key_perm_t		perm;		/* access permissions */
 	unsigned int		quotalen;	/* length added to quota */
-	unsigned short		datalen;	/* payload data length
+	unsigned int		datalen;	/* payload data length
 						 * - may not match RCU dereferenced payload
 						 * - payload should contain own length
 						 */
-- 
2.47.3

Re: [RFC PATCH 2/8] KEYS: Change the type of key->datalen to unsigned int

[David Howells]

I would merge this with patch 1.

Apart from that:

	Reviewed-by: David Howells <dhowells@redhat.com>

on both 1 & 2.

David

Re: [RFC PATCH 2/8] KEYS: Change the type of key->datalen to unsigned int

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 04:33:32PM +0100, David Howells wrote:
> I would merge this with patch 1.
> 
> Apart from that:
> 
> 	Reviewed-by: David Howells <dhowells@redhat.com>
> 
> on both 1 & 2.
> 
> David
> 

I can do that. I went a little over the top with sanity checking
the slop :-)

Br, Jarkko

Re: [RFC PATCH 2/8] KEYS: Change the type of key->datalen to unsigned int

[sashiko-bot]

> key_alloc() and key_payload_reserve() set key->datalen with values,
> which can be larger than USHRT_MAX.
> 
> Change the type from unsigned short to unsigned int.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

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

[RFC PATCH 3/8] KEYS: Reject @desclen values over U16_MAX in key_alloc()

[Jarkko Sakkinen]

@desclen in key_alloc() is saved to the 16-bit wide desc_len field in
struct keyring_index_key.

Reject @desclen values over U16_MAX with -EINVAL in order to prevent
integer overflow.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: f771fde82051 ("keys: Simplify key description management")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 security/keys/key.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/security/keys/key.c b/security/keys/key.c
index 6ebb8691551f..7888c0c6a772 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 */
-- 
2.47.3

Re: [RFC PATCH 3/8] KEYS: Reject @desclen values over U16_MAX in key_alloc()

[David Howells]

Jarkko Sakkinen <jarkko@kernel.org> wrote:

> Reject @desclen values over U16_MAX with -EINVAL in order to prevent
> integer overflow.

KEY_MAX_DESC_SIZE.

David

Re: [RFC PATCH 3/8] KEYS: Reject @desclen values over U16_MAX in key_alloc()

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 04:35:19PM +0100, David Howells wrote:
> Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> > Reject @desclen values over U16_MAX with -EINVAL in order to prevent
> > integer overflow.
> 
> KEY_MAX_DESC_SIZE.
> 
> David

Good catch, thanks.

Br, Jarkko

Re: [RFC PATCH 3/8] KEYS: Reject @desclen values over U16_MAX in key_alloc()

[sashiko-bot]

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

[RFC PATCH 4/8] KEYS: Prevent overflow of user->qnkeys in key_alloc()

[Jarkko Sakkinen]

Add the missing check rejecting allocations when user->qnkeys has reached
INT_MAX.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: 7e047ef5fe2d ("[PATCH] keys: sort out key quota system")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 security/keys/key.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/security/keys/key.c b/security/keys/key.c
index 7888c0c6a772..30f8a8dea206 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -263,6 +263,9 @@ struct key *key_alloc(struct key_type *type, const char *desc,
 			key_quota_root_maxbytes : key_quota_maxbytes;
 
 		spin_lock_irqsave(&user->lock, irqflags);
+		if (user->qnkeys == INT_MAX)
+			goto no_quota;
+
 		if (!(flags & KEY_ALLOC_QUOTA_OVERRUN)) {
 			if (user->qnkeys + 1 > maxkeys ||
 			    user->qnbytes + quotalen > maxbytes ||
-- 
2.47.3

Re: [RFC PATCH 4/8] KEYS: Prevent overflow of user->qnkeys in key_alloc()

[sashiko-bot]

> Add the missing check rejecting allocations when user->qnkeys has reached
> INT_MAX.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: 7e047ef5fe2d ("[PATCH] keys: sort out key quota system")
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

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

[RFC PATCH 5/8] KEYS: Prevent overflow of quota in key_alloc()

[Jarkko Sakkinen]

Check that the calculated quota length does not go over INT_MAX.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: 7e047ef5fe2d ("[PATCH] keys: sort out key quota system")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 security/keys/key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 30f8a8dea206..18043251365f 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -245,7 +245,7 @@ struct key *key_alloc(struct key_type *type, const char *desc,
 	}
 
 	desclen = strlen(desc);
-	if (desclen > U16_MAX)
+	if (desclen > U16_MAX || type->def_datalen > INT_MAX - desclen - 1)
 		goto error;
 	quotalen = desclen + 1 + type->def_datalen;
 
-- 
2.47.3

Re: [RFC PATCH 5/8] KEYS: Prevent overflow of quota in key_alloc()

[David Howells]

Jarkko Sakkinen <jarkko@kernel.org> wrote:

> -	if (desclen > U16_MAX)

This should also be KEY_MAX_DESC_SIZE.

> +	if (desclen > U16_MAX || type->def_datalen > INT_MAX - desclen - 1)

That looks awkward, but I can see why you did it.

Reviewed-by: David Howells <dhowells@redhat.com>

Re: [RFC PATCH 5/8] KEYS: Prevent overflow of quota in key_alloc()

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 04:40:47PM +0100, David Howells wrote:
> Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> > -	if (desclen > U16_MAX)
> 
> This should also be KEY_MAX_DESC_SIZE.
> 
> > +	if (desclen > U16_MAX || type->def_datalen > INT_MAX - desclen - 1)
> 
> That looks awkward, but I can see why you did it.
> 
> Reviewed-by: David Howells <dhowells@redhat.com>
> 

Do you mind if I do search-replace and apply these with
KEY_MAX_DESC_SIZE fixup?

Br, Jarkko

Re: [RFC PATCH 5/8] KEYS: Prevent overflow of quota in key_alloc()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] keys: u16 truncation of desc_len in __key_create_or_update()
--

commit ceebacfa6e4fbe645d2fe96b70fce1be4e928c92
Author: Jarkko Sakkinen <jarkko@kernel.org>

KEYS: Prevent overflow of quota in key_alloc()

This commit adds a check in key_alloc() to ensure that the calculated
quotalen does not exceed INT_MAX when combining desclen and
type->def_datalen.

> diff --git a/security/keys/key.c b/security/keys/key.c
> index 2996a387a3553..24d1c33ff87b4 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -245,7 +245,7 @@ struct key *key_alloc(struct key_type *type, const char *desc,
>  	}
>  
>  	desclen = strlen(desc);
> -	if (desclen > U16_MAX)
> +	if (desclen > U16_MAX || type->def_datalen > INT_MAX - desclen - 1)
>  		goto error;
>  	quotalen = desclen + 1 + type->def_datalen;
>  

[Severity: High]
Is checking desclen > U16_MAX in key_alloc() sufficient to prevent u16
truncation of index_key.desc_len in the __key_create_or_update() path?

In security/keys/key.c:__key_create_or_update(), when index_key.type->preparse
generates prep.description (or a caller passes a long description to
key_create_or_update() or key_create()), strlen(index_key.description) is
assigned directly to the u16 field index_key.desc_len and passed to
__key_link_begin() and find_key_to_update() before key_alloc() is ever
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);
	...
}

For example, when add_key("asymmetric", NULL, payload, plen, keyring) is
called with a crafted X.509 certificate, asn1_ber_decoder() caps the input
blob at datalen <= 65535, but x509_key_preparse() constructs
prep->description by hex-encoding cert->raw_serial (or cert->raw_skid) via
bin2hex(), which doubles its length:

crypto/asymmetric_keys/x509_public_key.c:x509_key_preparse() {
	...
	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;
	...
}

If a certificate has sulen == 0 and srlen == 32767 (with distinct issuer
and subject so x509_check_for_self_signed() skips signature verification),
strlen(prep.description) is 0 + 2 + 32767 * 2 = 65536 (U16_MAX + 1).

When __key_create_or_update() assigns 65536 to u16 index_key.desc_len, it
truncates to 0, and __key_link_begin() immediately hits a BUG_ON before
reaching key_alloc():

security/keys/keyring.c:__key_link_begin() {
	...
	BUG_ON(index_key->desc_len == 0);
	...
}

If strlen(index_key.description) exceeds U16_MAX and is not a multiple of
65536, index_key.desc_len truncates modulo 65536, causing
__key_link_begin() and find_key_to_update() to operate on a truncated
description length before key_alloc() can reject it.

Should __key_create_or_update() also validate strlen(index_key.description)
<= U16_MAX before assigning index_key.desc_len?

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

[RFC PATCH 6/8] KEYS: Prevent overflow of user->qnbytes in key_alloc()

[Jarkko Sakkinen]

Add the missing check rejecting resulting byte counts above INT_MAX.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: 7e047ef5fe2d ("[PATCH] keys: sort out key quota system")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 security/keys/key.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 18043251365f..5afc16425daf 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -263,7 +263,8 @@ struct key *key_alloc(struct key_type *type, const char *desc,
 			key_quota_root_maxbytes : key_quota_maxbytes;
 
 		spin_lock_irqsave(&user->lock, irqflags);
-		if (user->qnkeys == INT_MAX)
+		if (user->qnkeys == INT_MAX ||
+		    quotalen > INT_MAX - user->qnbytes)
 			goto no_quota;
 
 		if (!(flags & KEY_ALLOC_QUOTA_OVERRUN)) {
-- 
2.47.3

Re: [RFC PATCH 6/8] KEYS: Prevent overflow of user->qnbytes in key_alloc()

[David Howells]

I suggest merging patches 4 and 6, then add:

	Reviewed-by: David Howells <dhowells@redhat.com>

Re: [RFC PATCH 6/8] KEYS: Prevent overflow of user->qnbytes in key_alloc()

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 04:41:45PM +0100, David Howells wrote:
> I suggest merging patches 4 and 6, then add:
> 
> 	Reviewed-by: David Howells <dhowells@redhat.com>

Ok, I'll merge 1-2 and 4-6 both and apply, thanks.

Br, Jarkko

Re: [RFC PATCH 6/8] KEYS: Prevent overflow of user->qnbytes in key_alloc()

[sashiko-bot]

> Add the missing check rejecting resulting byte counts above INT_MAX.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: 7e047ef5fe2d ("[PATCH] keys: sort out key quota system")
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

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

[RFC PATCH 7/8] KEYS: Reject @datalen values over INT_MAX

[Jarkko Sakkinen]

Protect quota from overflowing by rejecting @datalen values that
surpass over INT_MAX.

Cc: stable@vger.kernel.org
Assisted-by: LLM
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
 security/keys/key.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/security/keys/key.c b/security/keys/key.c
index 5afc16425daf..5718ae7b80e5 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -379,11 +379,16 @@ EXPORT_SYMBOL(key_alloc);
  */
 int key_payload_reserve(struct key *key, size_t datalen)
 {
-	int delta = (int)datalen - key->datalen;
+	int delta;
 	int ret = 0;
 
 	key_check(key);
 
+	if (datalen > INT_MAX)
+		return -EINVAL;
+
+	delta = (int)datalen - key->datalen;
+
 	/* contemplate the quota adjustment */
 	if (delta != 0 && test_bit(KEY_FLAG_IN_QUOTA, &key->flags)) {
 		unsigned maxbytes = uid_eq(key->user->uid, GLOBAL_ROOT_UID) ?
-- 
2.47.3

Re: [RFC PATCH 7/8] KEYS: Reject @datalen values over INT_MAX

[David Howells]

Jarkko Sakkinen <jarkko@kernel.org> wrote:

> -	int delta = (int)datalen - key->datalen;
> +	int delta;
>  	int ret = 0;
>  
>  	key_check(key);
>  
> +	if (datalen > INT_MAX)
> +		return -EINVAL;
> +
> +	delta = (int)datalen - key->datalen;
> +

You don't actually need to move the subtraction.

But apart from that:

Signed-off-by: David Howells <dhowells@redhat.com>

Re: [RFC PATCH 7/8] KEYS: Reject @datalen values over INT_MAX

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 04:43:27PM +0100, David Howells wrote:
> Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> > -	int delta = (int)datalen - key->datalen;
> > +	int delta;
> >  	int ret = 0;
> >  
> >  	key_check(key);
> >  
> > +	if (datalen > INT_MAX)
> > +		return -EINVAL;
> > +
> > +	delta = (int)datalen - key->datalen;
> > +
> 
> You don't actually need to move the subtraction.

Ouch, you're right, I'll fixup that.

> 
> But apart from that:
> 
> Signed-off-by: David Howells <dhowells@redhat.com>

Br, Jarkko

Re: [RFC PATCH 7/8] KEYS: Reject @datalen values over INT_MAX

[sashiko-bot]

> Protect quota from overflowing by rejecting @datalen values that
> surpass over INT_MAX.
> 
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

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

[RFC PATCH 8/8] KEYS: Verify the key identity in __keyctl_unlink

[Jarkko Sakkinen]

Let's define the following preconditions:

- Two keys: A and B.
- R is a keyring.
- Both have the same type/description/domain.

Then:

1. KEYCTL_LINK(A, R) => {A}
1. KEYCTL_LINK(B, R) => {B}
2. KEYCTL_UNLINK(A, R) => {}

Instead, verify key tidentity before unlinking, and return -ENOENT on
mismatch.

Cc: stable@vger.kernel.org
Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
Assisted-by: LLM
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 7143f3079d20..b025331488c5 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -1501,9 +1501,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: [RFC PATCH 8/8] KEYS: Verify the key identity in __keyctl_unlink

[David Howells]

This will show it:

	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 show
	keyctl link $A %:R
	keyctl show
	keyctl link $B %:R
	keyctl show
	keyctl unlink $A %:R
	keyctl show  # R is now incorrectly empty

Reviewed-by: David Howells <dhowells@redhat.com>

Re: [RFC PATCH 8/8] KEYS: Verify the key identity in __keyctl_unlink

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 04:55:13PM +0100, David Howells wrote:
> This will show it:
> 
> 	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 show
> 	keyctl link $A %:R
> 	keyctl show
> 	keyctl link $B %:R
> 	keyctl show
> 	keyctl unlink $A %:R
> 	keyctl show  # R is now incorrectly empty
> 
> Reviewed-by: David Howells <dhowells@redhat.com>

I'll actually add this to my own test harness, thanks.

I'm a slightly worried of this patch given that you can
technically interpret it as a uapi change. I guess here it
is acceptable, and if a tree falls down, we'll respond
to that.

Br, Jarkko

Re: [RFC PATCH 8/8] KEYS: Verify the key identity in __keyctl_unlink

[sashiko-bot]

> Let's define the following preconditions:
> 
> - Two keys: A and B.
> - R is a keyring.
> - Both have the same type/description/domain.
> 
> Then:
> 
> 1. KEYCTL_LINK(A, R) => {A}
> 1. KEYCTL_LINK(B, R) => {B}
> 2. KEYCTL_UNLINK(A, R) => {}
> 
> Instead, verify key tidentity before unlinking, and return -ENOENT on
> mismatch.
> 
> Cc: stable@vger.kernel.org
> Fixes: b2a4df200d57 ("KEYS: Expand the capacity of a keyring")
> Assisted-by: LLM
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

Sashiko has reviewed this patch and found no issues.

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

Re: [RFC PATCH 0/8] KEYS: rhashtable bug fixes

[Jarkko Sakkinen]

On Mon, Oct 19, 2026 at 05:25:00PM +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 like to document any possible LLM association mostly for
self-reflection. I'm still adapting and not fully comfortable
with every detail so this gives a chance to look back and
learn how to do things better in the future.

So I'm neither supporter or desupporter of LLMs but more
like representing the "I don't know what to think about this"
camp :-)

Somewhat fuzzy opinion I have that more guards and checks
should be set to the patch submission process to address
"proxy contributors". At high rate such fixes are right
bug but wrong fix type of situations where author is
really not an author but instead a reporter. This is both
time consuming and unfair for legit contributors.

> 
> Jarkko Sakkinen (8):
>   KEYS: Change the type of key->quotalen to unsigned int
>   KEYS: Change the type of key->datalen to unsigned int
>   KEYS: Reject @desclen values over U16_MAX in key_alloc()
>   KEYS: Prevent overflow of user->qnkeys in key_alloc()
>   KEYS: Prevent overflow of quota in key_alloc()
>   KEYS: Prevent overflow of user->qnbytes in key_alloc()
>   KEYS: Reject @datalen values over INT_MAX
>   KEYS: Verify the key identity in __keyctl_unlink
> 
>  include/linux/key.h     |  4 ++--
>  security/keys/key.c     | 13 ++++++++++++-
>  security/keys/keyring.c |  6 ++++++
>  3 files changed, 20 insertions(+), 3 deletions(-)
> 
> --
> 2.47.3
> 

Br, Jarkko