From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linuxfoundation.org ([140.211.169.12]:50470 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932983AbdLRMKQ (ORCPT ); Mon, 18 Dec 2017 07:10:16 -0500 Subject: Patch "KEYS: Don't permit request_key() to construct a new keyring" has been added to the 3.18-stable tree To: dhowells@redhat.com, ebiggers@google.com, gregkh@linuxfoundation.org Cc: , From: Date: Mon, 18 Dec 2017 13:10:10 +0100 Message-ID: <15135990102944@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org List-ID: This is a note to let you know that I've just added the patch titled KEYS: Don't permit request_key() to construct a new keyring to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: keys-don-t-permit-request_key-to-construct-a-new-keyring.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >>From 911b79cde95c7da0ec02f48105358a36636b7a71 Mon Sep 17 00:00:00 2001 From: David Howells Date: Mon, 19 Oct 2015 11:20:28 +0100 Subject: KEYS: Don't permit request_key() to construct a new keyring From: David Howells commit 911b79cde95c7da0ec02f48105358a36636b7a71 upstream. If request_key() is used to find a keyring, only do the search part - don't do the construction part if the keyring was not found by the search. We don't really want keyrings in the negative instantiated state since the rejected/negative instantiation error value in the payload is unioned with keyring metadata. Now the kernel gives an error: request_key("keyring", "#selinux,bdekeyring", "keyring", KEY_SPEC_USER_SESSION_KEYRING) = -1 EPERM (Operation not permitted) Signed-off-by: David Howells Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman --- security/keys/request_key.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -467,6 +467,9 @@ static struct key *construct_key_and_lin if (ret) goto error; + if (ctx->index_key.type == &key_type_keyring) + return ERR_PTR(-EPERM); + user = key_user_lookup(current_fsuid()); if (!user) { ret = -ENOMEM; Patches currently in stable-queue which might be from dhowells@redhat.com are queue-3.18/keys-don-t-permit-request_key-to-construct-a-new-keyring.patch queue-3.18/don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-keyring.patch