All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cen Zhang <zzzccc427@gmail.com>
To: dhowells@redhat.com, jarkko@kernel.org, paul@paul-moore.com,
	jmorris@namei.org, serge@hallyn.com
Cc: keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
	jjzuming@gmail.com, zzzccc427@gmail.com
Subject: [PATCH] keys: Protect the read method check against type removal
Date: Sat, 17 Oct 2026 15:30:56 +0800	[thread overview]
Message-ID: <pm-key-management-objects-candidate-0010-v5-c6b7ca2813c6913e500a@gmail.com> (raw)

The key type must remain alive while its read method is checked.
keyctl_read_key() holds a reference to the key, but checks
key->type->read without holding key->sem. The reference keeps the key
alive, but does not pin the module containing its type.

With AF_RXRPC built as a module, a positive RxRPC key can pass
key_read_state() and the Read permission or possession checks while
another task unloads the module. Unload is possible once the module
refcount reaches zero, e.g. when no RxRPC socket remains open. The
reader can be delayed between loading key->type and reading its read
member, allowing this order:

  KEYCTL_READ task                  Module unload and key GC
  lookup_user_key()
  key_read_state()
  key_permission() / is_key_possessed()
  load key->type
                                    af_rxrpc_exit()
                                    unregister_key_type()
                                    key_gc_keytype() schedules the GC
                                      pass and waits for it
                                    GC takes key->sem for writing
                                    GC retypes key to key_type_dead
                                    GC releases key->sem
                                    unregister_key_type() returns
                                    free_module() frees type storage
  read saved type's read member

The last access reads freed module storage and can fault in
keyctl_read_key(). The later read invocation is already protected by
key->sem and key_validate() in __keyctl_read_key(), but neither covers
this earlier check.

Take key->sem for reading around the read-method check. The garbage
collector retypes the key under a write hold on key->sem, so it must
wait for the check to finish; key_gc_keytype() in turn waits for that
GC pass before unregister_key_type() returns, so the module text cannot
be freed until the check has completed. If retyping happens first, the
check sees key_type_dead, which has no read method. Release the
semaphore before returning -EOPNOTSUPP or proceeding to buffer
allocation, preserving the early unsupported-operation result and
keeping user copies outside the semaphore.

Oops report as below:

    BUG: unable to handle page fault for address: fffffbfff8048bc5
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    RIP: 0010:keyctl_read_key+0x1aa/0x600
    Call Trace:
     __do_sys_keyctl+0x2a7/0x4f0

Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Assisted-by: LLM

---
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index 5a5efa26ed0e..756368422b7c 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -863,10 +863,13 @@ long keyctl_read_key(key_serial_t keyid, char __user *buffer, size_t buflen)
 
 	/* the key is probably readable - now try to read it */
 can_read_key:
-	if (!key->type->read) {
-		ret = -EOPNOTSUPP;
+	down_read(&key->sem);
+	ret = -EOPNOTSUPP;
+	if (key->type->read)
+		ret = 0;
+	up_read(&key->sem);
+	if (ret)
 		goto key_put_out;
-	}
 
 	if (!buffer || !buflen) {
 		/* Get the key length from the read method */

             reply	other threads:[~2026-10-17  7:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17  7:30 Cen Zhang [this message]
2026-10-17  7:49 ` [PATCH] keys: Protect the read method check against type removal sashiko-bot

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=pm-key-management-objects-candidate-0010-v5-c6b7ca2813c6913e500a@gmail.com \
    --to=zzzccc427@gmail.com \
    --cc=baijiaju1990@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=jarkko@kernel.org \
    --cc=jjzuming@gmail.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --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.