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
next prev parent 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®