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 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.