From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793209897; b=EeQQoLIFvguRI81iS+mbIuO++DqHYjAJq3VRKHzYXlXj2Qs4NxGP3LHv6sW4JMbCVQWl K50VZEu3BwC9hCGcwsR1HVQQQPn1Jnw701ApO9MqZr5YKJwIu7LRwK8E/b0oR8o+Q0OWM wNsWvPGkMEqMaTFSWG1ztPCWZnr8iNVgczvAuYrVjP0P6zqmUoftlobAS5oqRUWrCemRl zKSeXjBXOdzGlAzJ5wUrdkfoh9udZkrAlfxjNSC79J4ZLIU3Qeh4vBFNvZLzV1daUEr4R AOCJTiOJ+FE7/b31SIw6g0DQrYOEjLy47PqFtWdyUSkxUaUQ1dy8yPnKSqRSFK8/UAw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793209897; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=N3BDjYiK9milVdqFKw+XYb6NOn50ylPKULBzWBmkwZg=; b=kvelWJNtIcfgL4bAWMH+d8lZhRAv7P5r1wjjJW45/WccFu05t9zYAGM4MZUwPnwpZ790 qXIhadyi2myCf2Vai2yKNcqJUfzNZsjY2nNZ7H32+tDWJWjccoTWinHcoYCTktf2FBQEi 9JFyoPcULsDCqce3ffjau6SBNT7mgNb3UYE6MKvq+5qpGidpGx8w4zD0ohbHnF01lExWB MjokPDp/XEWhr6YoswgnmNfyDhoFmSXhtDuFGQSJSbdxmw6QFE0VAYmDkY/u0fnlF9FlH gGCPElkwT62Gm+2Vc0f4+KrMqPAKqj0k7wSlo0nxf/xDkut/jEfLSISYoS03jVQxiuA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=CBu2u9sM; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1A21606A31A; Wed, 28 Oct 2026 17:51:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=CBu2u9sM Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FAE51F01825; Wed, 28 Oct 2026 17:51:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793209896; bh=N3BDjYiK9milVdqFKw+XYb6NOn50ylPKULBzWBmkwZg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=CBu2u9sMj9KfsjoyVNqetoNVI5zioydM305FbHKCxWO9reMnxplY/X/xpGdVo2kHe tMHdAQ6FD3a6J5xp+Mi5wEkQsGLHeuRN5fItBeNDabETki8hrUDDFDhurldJsixPxH WJ6Hwxp+fASutY2JpczunmSU7fCt4R9BqIQn0b2E= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Jarkko Sakkinen , Cen Zhang , David Howells Subject: [PATCH 6.18 095/109] keys: Protect the read method check against type removal Date: Wed, 28 Oct 2026 18:01:19 +0100 Message-ID: <20261028165944.590354493@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261028165942.357251485@linuxfoundation.org> References: <20261028165942.357251485@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Cen Zhang commit 925c84e3cc21caf09de92d9bcafab0147790debf upstream. keyctl_read_key() checks key->type->read without holding key->sem. A reference keeps the key alive, but does not pin the module containing its type. A surviving RxRPC key can therefore be read while AF_RXRPC is being unloaded: KEYCTL_READ task Module unload and key GC ---------------- ------------------------ lookup_user_key() permission / possession checks load key->type af_rxrpc_exit() unregister_key_type() GC: down_write(key->sem) GC: retype to key_type_dead GC: up_write(key->sem) unregister_key_type() returns free_module() read saved type's read member The final access can read freed module storage. The read invocation in __keyctl_read_key() is already protected by key->sem, but the earlier method check is outside that critical section. Move the method check into __keyctl_read_key(), after key_validate() and under its existing read hold on key->sem. The check and invocation then use the same protected type for length queries and every read retry. The GC cannot retype the key until the semaphore is released, and type unregistration waits for that GC pass before the module can be freed. Return -EOPNOTSUPP when validation succeeds and the type has no read method. A temporary buffer may now be allocated before this result; allocation and copying to userspace remain outside the semaphore. Assisted-by: LLM Cc: stable@vger.kernel.org # v5.10+ Fixes: d3ec10aa9581 ("KEYS: Don't write out to userspace while holding key semaphore") Suggested-by: Jarkko Sakkinen Signed-off-by: Cen Zhang Reviewed-by: Jarkko Sakkinen Reviewed-by: David Howells Link: https://lore.kernel.org/r/pm-key-management-objects-candidate-0010-v7-fc85721ff5cfb9e33ac6@gmail.com Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman --- security/keys/keyctl.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) --- a/security/keys/keyctl.c +++ b/security/keys/keyctl.c @@ -808,8 +808,12 @@ static long __keyctl_read_key(struct key down_read(&key->sem); ret = key_validate(key); - if (ret == 0) - ret = key->type->read(key, buffer, buflen); + if (ret == 0) { + if (key->type->read) + ret = key->type->read(key, buffer, buflen); + else + ret = -EOPNOTSUPP; + } up_read(&key->sem); return ret; } @@ -863,11 +867,6 @@ long keyctl_read_key(key_serial_t keyid, /* the key is probably readable - now try to read it */ can_read_key: - if (!key->type->read) { - ret = -EOPNOTSUPP; - goto key_put_out; - } - if (!buffer || !buflen) { /* Get the key length from the read method */ ret = __keyctl_read_key(key, NULL, 0);