All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>
To: Daehyeon Ko <4ncienth@gmail.com>
Cc: dhowells@redhat.com, jarkko@kernel.org, lukas@wunner.de,
	ignat@linux.win, paul@paul-moore.com, jmorris@namei.org,
	serge@hallyn.com, herbert@gondor.apana.org.au,
	davem@davemloft.net, keyrings@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] keys: reject descriptions that exceed the index length
Date: Fri, 28 Aug 2026 15:42:50 +0530	[thread overview]
Message-ID: <C7DCED4F-152E-4B3A-AB4D-FFBF36715168@linux.ibm.com> (raw)
In-Reply-To: <20260828080728.2641312-1-4ncienth@gmail.com>



> On 28 Aug 2026, at 1:37 PM, Daehyeon Ko <4ncienth@gmail.com> wrote:
> 
> struct keyring_index_key::desc_len is a u16.  User-provided key
> descriptions are limited to 4095 bytes, but a key type preparser can
> generate a longer description when the caller passes NULL.
> 
> The X.509 parser forms a description from the certificate subject and
> twice the raw serial length when the certificate has no Subject Key
> Identifier.  A certificate with a two-byte subject and a 32766-byte serial
> therefore produces a 65536-byte description.  Assigning strlen() to
> desc_len wraps it to zero, after which __key_link_begin() hits:
> 
>    BUG_ON(index_key->desc_len == 0);
> 
> This was reproduced through keyctl on a v6.12.105 KASAN kernel with
> panic=1 and oops=panic.  The process ran as uid and gid 1000 with no
> capabilities, and the console recorded:
> 
>    CapInh: 0000000000000000
>    CapPrm: 0000000000000000
>    CapEff: 0000000000000000
>    [   14.044055] ------------[ cut here ]------------
>    [   14.044211] kernel BUG at security/keys/keyring.c:1308!
>    [   14.044375] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
>    [   14.044558] CPU: 0 UID: 1000 PID: 138 Comm: keyctl Not tainted 6.12.105-dirty #1
>    [   14.044788] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
>    [   14.045025] RIP: 0010:__key_link_begin+0x1e5/0x250
>    [   14.047630] Call Trace:
>    [   14.047711]  <TASK>
>    [   14.047785]  __key_create_or_update+0x490/0xcd0
>    [   14.047954]  ? __pfx___key_create_or_update+0x10/0x10
>    [   14.048139]  ? __pfx_lookup_user_key_possessed+0x10/0x10
>    [   14.048323]  key_create_or_update+0x47/0x60
>    [   14.048484]  __do_sys_add_key+0x219/0x430
>    [   14.048632]  ? __pfx___do_sys_add_key+0x10/0x10
>    [   14.048794]  ? switch_fpu_return+0x127/0x250
>    [   14.048980]  ? srso_return_thunk+0x5/0x5f
>    [   14.049163]  ? arch_exit_to_user_mode_prepare.constprop.0+0x6f/0xa0
>    [   14.049417]  ? srso_return_thunk+0x5/0x5f
>    [   14.049582]  do_syscall_64+0x5a/0x130
>    [   14.049721]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
>    [   14.051772]  </TASK>
>    [   14.051975] ---[ end trace 0000000000000000 ]---
>    [   14.054729] Kernel panic - not syncing: Fatal exception
> 
> The same boundary was independently reproduced on 3/3 fresh v6.12.105
> KASAN boots with the source reproducer.
> 
> A one-byte-short control with a 32765-byte serial parsed successfully and
> returned EDQUOT without a splat, showing that the wrap boundary is causal.
> 
> Measure generated descriptions before narrowing the length and reject
> values that cannot be represented.  On 3/3 fresh patched mainline KASAN
> boots, the boundary returned EINVAL and the control continued to return
> EDQUOT, with no BUG, Oops, KASAN report, warning or panic.
> 
> A tested source reproducer exists and is available to maintainers
> privately.
> 
> Fixes: f771fde82051 ("keys: Simplify key description management")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>


Reviewed-by: Sudhakar Kuppusamy <sudhakar@linux.ibm.com>


Thanks,
Sudhakar

> ---
> Changes in v2:
> - Add the observed keyctl crash trace and before/after runtime results to the
>  commit message.
> - Clarify that the serial is used when the certificate has no Subject Key
>  Identifier.
> - No code changes.
> 
> security/keys/key.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/security/keys/key.c b/security/keys/key.c
> index b34a64d81d47ab..f2f472b45f4eee 100644
> --- a/security/keys/key.c
> +++ b/security/keys/key.c
> @@ -14,6 +14,7 @@
> #include <linux/workqueue.h>
> #include <linux/random.h>
> #include <linux/err.h>
> +#include <linux/limits.h>
> #include "internal.h"
> 
> struct kmem_cache *key_jar;
> @@ -820,6 +821,7 @@ static key_ref_t __key_create_or_update(key_ref_t keyring_ref,
> const struct cred *cred = current_cred();
> struct key *keyring, *key = NULL;
> key_ref_t key_ref;
> + size_t desc_len;
> int ret;
> struct key_restriction *restrict_link = NULL;
> 
> @@ -865,7 +867,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);
> + desc_len = strlen(index_key.description);
> + if (desc_len > U16_MAX) {
> + key_ref = ERR_PTR(-EINVAL);
> + goto error_free_prep;
> + }
> + index_key.desc_len = desc_len;
> key_set_index_key(&index_key);
> 
> ret = __key_link_lock(keyring, &index_key);
> 
> base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
> -- 
> 2.54.0
> 


      reply	other threads:[~2026-08-28 10:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 11:30 [PATCH] keys: reject descriptions that exceed the index length Daehyeon Ko
2026-08-28  5:02 ` Jarkko Sakkinen
2026-08-28  5:38   ` Daehyeon Ko
2026-08-28  8:07     ` [PATCH v2] " Daehyeon Ko
2026-08-28 10:12       ` Sudhakar Kuppusamy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C7DCED4F-152E-4B3A-AB4D-FFBF36715168@linux.ibm.com \
    --to=sudhakar@linux.ibm.com \
    --cc=4ncienth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ignat@linux.win \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.