[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