From: Daehyeon Ko <4ncienth@gmail.com>
To: keyrings@vger.kernel.org, David Howells <dhowells@redhat.com>
Cc: Lukas Wunner <lukas@wunner.de>, Ignat Korchagin <ignat@linux.win>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
Mat Martineau <martineau@kernel.org>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Daehyeon Ko <4ncienth@gmail.com>
Subject: [PATCH] KEYS: asymmetric: reject non-positive restriction keys
Date: Thu, 13 Aug 2026 21:40:10 +0900 [thread overview]
Message-ID: <20260813124010.2546648-1-4ncienth@gmail.com> (raw)
asymmetric_lookup_restriction() resolves the serial in a
key_or_keyring restriction with key_lookup(). This can return a negative
or uninstantiated key as well as a positive one, and the restriction then
retains that key.
When the key has the asymmetric type, key_or_keyring_common() treats it as
a usable trust key and dereferences asymmetric_key_ids(trusted). Negative
asymmetric keys have no payload, so linking an asymmetric key to the
restricted keyring causes a NULL pointer dereference.
A process can retain a negative asymmetric key after a request_key() upcall
fails and use its serial to restrict a keyring it owns. Linking a valid
X.509 key to that keyring then triggers the fault without special
privileges. On systems configured to panic on oops, this is a local denial
of service.
KASAN reports:
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
RIP: 0010:key_or_keyring_common+0x688/0x880
Call Trace:
key_link+0x1e1/0x300
keyctl_keyring_link+0x6e/0xc0
__do_sys_keyctl+0x299/0x530
Reject keys that have not been positively instantiated before installing
the restriction. The explicit NULL trust key used by
key_or_keyring:0:chain remains unaffected.
Fixes: 7e3c4d22083f ("KEYS: Restrict asymmetric key linkage using a specific keychain")
Cc: stable@vger.kernel.org
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
---
crypto/asymmetric_keys/asymmetric_type.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/crypto/asymmetric_keys/asymmetric_type.c b/crypto/asymmetric_keys/asymmetric_type.c
index 16a7ae16593c9e..ce78dbc8b8c1cc 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -553,6 +553,11 @@ static struct key_restriction *asymmetric_lookup_restriction(
ret = ERR_CAST(key);
goto out;
}
+ if (!key_is_positive(key)) {
+ key_put(key);
+ ret = ERR_PTR(-ENOKEY);
+ goto out;
+ }
}
ret = asymmetric_restriction_alloc(link_fn, key);
base-commit: 3d6d817622b0a9721e3cc404df3469171582be13
--
2.54.0
reply other threads:[~2026-08-13 12:40 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260813124010.2546648-1-4ncienth@gmail.com \
--to=4ncienth@gmail.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=ignat@linux.win \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=martineau@kernel.org \
/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