mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Daehyeon Ko <4ncienth@gmail.com>
Cc: dhowells@redhat.com, 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] keys: reject descriptions that exceed the index length
Date: Fri, 28 Aug 2026 08:02:29 +0300	[thread overview]
Message-ID: <apEWZUFe8NmwgPDb@kernel.org> (raw)
In-Reply-To: <20260824113004.3755053-1-4ncienth@gmail.com>

On Mon, Aug 24, 2026 at 08:30:04PM +0900, Daehyeon Ko 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.  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 is reachable through add_key() by an unprivileged user and can panic
> the kernel when oopses are fatal.
> 
> Measure generated descriptions before narrowing the length and reject
> values that cannot be represented.  The boundary input now returns EINVAL,
> while the one-byte-short control still reaches the normal quota check.

This lacks smoking gun type of evidence, and I don't understand why
as it requires an extremely low effort.

If I understood the code correctly, I'd start with a key that I would
craft along the lines of:

    openssl genpkey -algorithm Ed25519 -out key.bin

    openssl req -x509 -key key.bin \
                      -outform DER \
                      -out certificate.bin \
                      -subj "/CN=xx" \
                      -set_serial "0x7f$(head -c 65530 /dev/zero | tr '\0' 'f')"

Then I would simply expect this to crash my system:

    keyctl padd asymmetric %:s @s < certificate.bin

Will this happen? Have not tried it in a VM yet. I just feel a bit
confused that this was not already demontrated in the commit message,
which makes me think that I get something wrong?

BR, Jarkko

  reply	other threads:[~2026-08-28  5:02 UTC|newest]

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

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=apEWZUFe8NmwgPDb@kernel.org \
    --to=jarkko@kernel.org \
    --cc=4ncienth@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ignat@linux.win \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®