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

[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

[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

[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