December 2017 - Linux-stable-mirror

[Linux-stable-mirror] Stable inclusion of "mfd: lpc_ich: Do not touch SPI-NOR write protection bit on Haswell/Broadwell"

by Mika Westerberg

Hi, Can following commit be included in stable kernel releases starting from v4.11? d9018976cdb6eefc62a7ba79a405f6c9661b08a7 ("mfd: lpc_ich: Do not touch SPI-NOR write protection bit on Haswell/Broadwell") This makes sure older kernels will not accidentally lose the BIOS settings. Thanks!

7 years

2
3
0 0

[Linux-stable-mirror] Patch "mac80211: Fix addition of mesh configuration element" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Fix addition of mesh configuration element to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-fix-addition-of-mesh-configuration-element.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 57629915d568c522ac1422df7bba4bee5b5c7a7c Mon Sep 17 00:00:00 2001 From: Ilan peer <ilan.peer(a)intel.com> Date: Mon, 26 Dec 2016 18:17:36 +0200 Subject: mac80211: Fix addition of mesh configuration element From: Ilan peer <ilan.peer(a)intel.com> commit 57629915d568c522ac1422df7bba4bee5b5c7a7c upstream. The code was setting the capabilities byte to zero, after it was already properly set previously. Fix it. The bug was found while debugging hwsim mesh tests failures that happened since the commit mentioned below. Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization") Signed-off-by: Ilan Peer <ilan.peer(a)intel.com> Reviewed-by: Masashi Honma <masashi.honma(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Cc: Richard Schütz <rschuetz(a)uni-koblenz.de> Cc: Mathias Kretschmer <mathias.kretschmer(a)fit.fraunhofer.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh.c | 2 -- 1 file changed, 2 deletions(-) --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -279,8 +279,6 @@ int mesh_add_meshconf_ie(struct ieee8021 /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ *pos |= ifmsh->ps_peers_deep_sleep ? IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; - *pos++ = 0x00; - return 0; } Patches currently in stable-queue which might be from ilan.peer(a)intel.com are queue-4.9/mac80211-fix-addition-of-mesh-configuration-element.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: Fix addition of mesh configuration element" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Fix addition of mesh configuration element to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-fix-addition-of-mesh-configuration-element.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 57629915d568c522ac1422df7bba4bee5b5c7a7c Mon Sep 17 00:00:00 2001 From: Ilan peer <ilan.peer(a)intel.com> Date: Mon, 26 Dec 2016 18:17:36 +0200 Subject: mac80211: Fix addition of mesh configuration element From: Ilan peer <ilan.peer(a)intel.com> commit 57629915d568c522ac1422df7bba4bee5b5c7a7c upstream. The code was setting the capabilities byte to zero, after it was already properly set previously. Fix it. The bug was found while debugging hwsim mesh tests failures that happened since the commit mentioned below. Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization") Signed-off-by: Ilan Peer <ilan.peer(a)intel.com> Reviewed-by: Masashi Honma <masashi.honma(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Cc: Richard Schütz <rschuetz(a)uni-koblenz.de> Cc: Mathias Kretschmer <mathias.kretschmer(a)fit.fraunhofer.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh.c | 2 -- 1 file changed, 2 deletions(-) --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -295,8 +295,6 @@ int mesh_add_meshconf_ie(struct ieee8021 /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ *pos |= ifmsh->ps_peers_deep_sleep ? IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; - *pos++ = 0x00; - return 0; } Patches currently in stable-queue which might be from ilan.peer(a)intel.com are queue-4.4/mac80211-fix-addition-of-mesh-configuration-element.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: add missing permission check for request_key() destination" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KEYS: add missing permission check for request_key() destination to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: keys-add-missing-permission-check-for-request_key-destination.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4dca6ea1d9432052afb06baf2e3ae78188a4410b Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Fri, 8 Dec 2017 15:13:27 +0000 Subject: KEYS: add missing permission check for request_key() destination From: Eric Biggers <ebiggers(a)google.com> commit 4dca6ea1d9432052afb06baf2e3ae78188a4410b upstream. When the request_key() syscall is not passed a destination keyring, it links the requested key (if constructed) into the "default" request-key keyring. This should require Write permission to the keyring. However, there is actually no permission check. This can be abused to add keys to any keyring to which only Search permission is granted. This is because Search permission allows joining the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING) then will set the default request-key keyring to the session keyring. Then, request_key() can be used to add keys to the keyring. Both negatively and positively instantiated keys can be added using this method. Adding negative keys is trivial. Adding a positive key is a bit trickier. It requires that either /sbin/request-key positively instantiates the key, or that another thread adds the key to the process keyring at just the right time, such that request_key() misses it initially but then finds it in construct_alloc_key(). Fix this bug by checking for Write permission to the keyring in construct_get_dest_keyring() when the default keyring is being used. We don't do the permission check for non-default keyrings because that was already done by the earlier call to lookup_user_key(). Also, request_key_and_link() is currently passed a 'struct key *' rather than a key_ref_t, so the "possessed" bit is unavailable. We also don't do the permission check for the "requestor keyring", to continue to support the use case described by commit 8bbf4976b59f ("KEYS: Alter use of key instantiation link-to-keyring argument") where /sbin/request-key recursively calls request_key() to add keys to the original requestor's destination keyring. (I don't know of any users who actually do that, though...) Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/request_key.c | 48 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 38 insertions(+), 10 deletions(-) --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -250,11 +250,12 @@ static int construct_key(struct key *key * The keyring selected is returned with an extra reference upon it which the * caller must release. */ -static void construct_get_dest_keyring(struct key **_dest_keyring) +static int construct_get_dest_keyring(struct key **_dest_keyring) { struct request_key_auth *rka; const struct cred *cred = current_cred(); struct key *dest_keyring = *_dest_keyring, *authkey; + int ret; kenter("%p", dest_keyring); @@ -263,6 +264,8 @@ static void construct_get_dest_keyring(s /* the caller supplied one */ key_get(dest_keyring); } else { + bool do_perm_check = true; + /* use a default keyring; falling through the cases until we * find one that we actually have */ switch (cred->jit_keyring) { @@ -277,8 +280,10 @@ static void construct_get_dest_keyring(s dest_keyring = key_get(rka->dest_keyring); up_read(&authkey->sem); - if (dest_keyring) + if (dest_keyring) { + do_perm_check = false; break; + } } case KEY_REQKEY_DEFL_THREAD_KEYRING: @@ -313,11 +318,29 @@ static void construct_get_dest_keyring(s default: BUG(); } + + /* + * Require Write permission on the keyring. This is essential + * because the default keyring may be the session keyring, and + * joining a keyring only requires Search permission. + * + * However, this check is skipped for the "requestor keyring" so + * that /sbin/request-key can itself use request_key() to add + * keys to the original requestor's destination keyring. + */ + if (dest_keyring && do_perm_check) { + ret = key_permission(make_key_ref(dest_keyring, 1), + KEY_NEED_WRITE); + if (ret) { + key_put(dest_keyring); + return ret; + } + } } *_dest_keyring = dest_keyring; kleave(" [dk %d]", key_serial(dest_keyring)); - return; + return 0; } /* @@ -442,12 +465,16 @@ static struct key *construct_key_and_lin if (ctx->index_key.type == &key_type_keyring) return ERR_PTR(-EPERM); - - user = key_user_lookup(current_fsuid()); - if (!user) - return ERR_PTR(-ENOMEM); - construct_get_dest_keyring(&dest_keyring); + ret = construct_get_dest_keyring(&dest_keyring); + if (ret) + goto error; + + user = key_user_lookup(current_fsuid()); + if (!user) { + ret = -ENOMEM; + goto error_put_dest_keyring; + } ret = construct_alloc_key(ctx, dest_keyring, flags, user, &key); key_user_put(user); @@ -462,7 +489,7 @@ static struct key *construct_key_and_lin } else if (ret == -EINPROGRESS) { ret = 0; } else { - goto couldnt_alloc_key; + goto error_put_dest_keyring; } key_put(dest_keyring); @@ -472,8 +499,9 @@ static struct key *construct_key_and_lin construction_failed: key_negate_and_link(key, key_negative_timeout, NULL, NULL); key_put(key); -couldnt_alloc_key: +error_put_dest_keyring: key_put(dest_keyring); +error: kleave(" = %d", ret); return ERR_PTR(ret); } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.4/crypto-salsa20-fix-blkcipher_walk-api-usage.patch queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch queue-4.4/crypto-hmac-require-that-the-underlying-hash-algorithm-is-unkeyed.patch

7 years

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] mac80211: Fix addition of mesh configuration element

by Greg KH

On Fri, Dec 15, 2017 at 11:31:27AM +0100, Richard Schütz wrote: > On 12/15/2017 10:49 AM, Greg KH wrote: > > On Fri, Dec 15, 2017 at 10:29:29AM +0100, Richard Schütz wrote: > > > From: Ilan peer <ilan.peer(a)intel.com> > > > > > > commit 57629915d568c522ac1422df7bba4bee5b5c7a7c upstream. > > > > > > The code was setting the capabilities byte to zero, > > > after it was already properly set previously. Fix it. > > > > > > The bug was found while debugging hwsim mesh tests failures > > > that happened since the commit mentioned below. > > > > > > Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization") > > > Signed-off-by: Ilan Peer <ilan.peer(a)intel.com> > > > Reviewed-by: Masashi Honma <masashi.honma(a)gmail.com> > > > Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> > > > Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de> > > > --- > > > net/mac80211/mesh.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c > > > index cc2a63bd233f..9c23172feba0 100644 > > > --- a/net/mac80211/mesh.c > > > +++ b/net/mac80211/mesh.c > > > @@ -279,8 +279,6 @@ int mesh_add_meshconf_ie(struct ieee80211_sub_if_data *sdata, > > > /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ > > > *pos |= ifmsh->ps_peers_deep_sleep ? > > > IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; > > > - *pos++ = 0x00; > > > - > > > return 0; > > > } > > > -- > > > 2.15.1 > > > > > > I'm sorry, I don't understand what you want done with this patch. Why > > send it to stable@? > > > > confused, > > > > greg k-h > > > > AUTOSEL picked up 76f43b4c0a93 for stable a short while ago, but not this > accompanying fix. Currently wireless mesh networking is severely impacted in > stable because of that. Ah, ok, thanks, that makes sense, now queued up. greg k-h

7 years

1
0
0 0

[Linux-stable-mirror] Patch "mac80211: Fix addition of mesh configuration element" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Fix addition of mesh configuration element 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=sum… The filename of the patch is: mac80211-fix-addition-of-mesh-configuration-element.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 <stable(a)vger.kernel.org> know about it. >From 57629915d568c522ac1422df7bba4bee5b5c7a7c Mon Sep 17 00:00:00 2001 From: Ilan peer <ilan.peer(a)intel.com> Date: Mon, 26 Dec 2016 18:17:36 +0200 Subject: mac80211: Fix addition of mesh configuration element From: Ilan peer <ilan.peer(a)intel.com> commit 57629915d568c522ac1422df7bba4bee5b5c7a7c upstream. The code was setting the capabilities byte to zero, after it was already properly set previously. Fix it. The bug was found while debugging hwsim mesh tests failures that happened since the commit mentioned below. Fixes: 76f43b4c0a93 ("mac80211: Remove invalid flag operations in mesh TSF synchronization") Signed-off-by: Ilan Peer <ilan.peer(a)intel.com> Reviewed-by: Masashi Honma <masashi.honma(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Cc: Richard Schütz <rschuetz(a)uni-koblenz.de> Cc: Mathias Kretschmer <mathias.kretschmer(a)fit.fraunhofer.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/mesh.c | 2 -- 1 file changed, 2 deletions(-) --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -289,8 +289,6 @@ int mesh_add_meshconf_ie(struct ieee8021 /* Mesh PS mode. See IEEE802.11-2012 8.4.2.100.8 */ *pos |= ifmsh->ps_peers_deep_sleep ? IEEE80211_MESHCONF_CAPAB_POWER_SAVE_LEVEL : 0x00; - *pos++ = 0x00; - return 0; } Patches currently in stable-queue which might be from ilan.peer(a)intel.com are queue-3.18/mac80211-fix-addition-of-mesh-configuration-element.patch

7 years

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: Don't permit request_key() to construct a new keyring" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

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=sum… 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 <stable(a)vger.kernel.org> know about it. >From 911b79cde95c7da0ec02f48105358a36636b7a71 Mon Sep 17 00:00:00 2001 From: David Howells <dhowells(a)redhat.com> Date: Mon, 19 Oct 2015 11:20:28 +0100 Subject: KEYS: Don't permit request_key() to construct a new keyring From: David Howells <dhowells(a)redhat.com> 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 <dhowells(a)redhat.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- 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(a)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

7 years

1
0
0 0

[Linux-stable-mirror] Patch "Don't leak a key reference if request_key() tries to use a revoked keyring" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Don't leak a key reference if request_key() tries to use a revoked 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=sum… The filename of the patch is: don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-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 <stable(a)vger.kernel.org> know about it. >From d0709f1e66e8066c4ac6a54620ec116aa41937c0 Mon Sep 17 00:00:00 2001 From: David Jeffery <djeffery(a)redhat.com> Date: Thu, 12 Feb 2015 16:45:31 +0000 Subject: Don't leak a key reference if request_key() tries to use a revoked keyring From: David Jeffery <djeffery(a)redhat.com> commit d0709f1e66e8066c4ac6a54620ec116aa41937c0 upstream. If a request_key() call to allocate and fill out a key attempts to insert the key structure into a revoked keyring, the key will leak, using memory and part of the user's key quota until the system reboots. This is from a failure of construct_alloc_key() to decrement the key's reference count after the attempt to insert into the requested keyring is rejected. key_put() needs to be called in the link_prealloc_failed callpath to ensure the unused key is released. Signed-off-by: David Jeffery <djeffery(a)redhat.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/request_key.c | 1 + 1 file changed, 1 insertion(+) --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -437,6 +437,7 @@ link_check_failed: link_prealloc_failed: mutex_unlock(&user->cons_lock); + key_put(key); kleave(" = %d [prelink]", ret); return ret; Patches currently in stable-queue which might be from djeffery(a)redhat.com are queue-3.18/don-t-leak-a-key-reference-if-request_key-tries-to-use-a-revoked-keyring.patch

7 years

1
0
0 0

[Linux-stable-mirror] [PATCH for 4.4] KEYS: add missing permission check for request_key() destination

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> commit 4dca6ea1d9432052afb06baf2e3ae78188a4410b upstream. [Please apply to 4.4-stable.] When the request_key() syscall is not passed a destination keyring, it links the requested key (if constructed) into the "default" request-key keyring. This should require Write permission to the keyring. However, there is actually no permission check. This can be abused to add keys to any keyring to which only Search permission is granted. This is because Search permission allows joining the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING) then will set the default request-key keyring to the session keyring. Then, request_key() can be used to add keys to the keyring. Both negatively and positively instantiated keys can be added using this method. Adding negative keys is trivial. Adding a positive key is a bit trickier. It requires that either /sbin/request-key positively instantiates the key, or that another thread adds the key to the process keyring at just the right time, such that request_key() misses it initially but then finds it in construct_alloc_key(). Fix this bug by checking for Write permission to the keyring in construct_get_dest_keyring() when the default keyring is being used. We don't do the permission check for non-default keyrings because that was already done by the earlier call to lookup_user_key(). Also, request_key_and_link() is currently passed a 'struct key *' rather than a key_ref_t, so the "possessed" bit is unavailable. We also don't do the permission check for the "requestor keyring", to continue to support the use case described by commit 8bbf4976b59f ("KEYS: Alter use of key instantiation link-to-keyring argument") where /sbin/request-key recursively calls request_key() to add keys to the original requestor's destination keyring. (I don't know of any users who actually do that, though...) Fixes: 3e30148c3d52 ("[PATCH] Keys: Make request-key create an authorisation key") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> --- security/keys/request_key.c | 48 +++++++++++++++++++++++++++++++++++---------- 1 file changed, 38 insertions(+), 10 deletions(-) diff --git a/security/keys/request_key.c b/security/keys/request_key.c index 2ce733342b5a..3ae3acf473c8 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -250,11 +250,12 @@ static int construct_key(struct key *key, const void *callout_info, * The keyring selected is returned with an extra reference upon it which the * caller must release. */ -static void construct_get_dest_keyring(struct key **_dest_keyring) +static int construct_get_dest_keyring(struct key **_dest_keyring) { struct request_key_auth *rka; const struct cred *cred = current_cred(); struct key *dest_keyring = *_dest_keyring, *authkey; + int ret; kenter("%p", dest_keyring); @@ -263,6 +264,8 @@ static void construct_get_dest_keyring(struct key **_dest_keyring) /* the caller supplied one */ key_get(dest_keyring); } else { + bool do_perm_check = true; + /* use a default keyring; falling through the cases until we * find one that we actually have */ switch (cred->jit_keyring) { @@ -277,8 +280,10 @@ static void construct_get_dest_keyring(struct key **_dest_keyring) dest_keyring = key_get(rka->dest_keyring); up_read(&authkey->sem); - if (dest_keyring) + if (dest_keyring) { + do_perm_check = false; break; + } } case KEY_REQKEY_DEFL_THREAD_KEYRING: @@ -313,11 +318,29 @@ static void construct_get_dest_keyring(struct key **_dest_keyring) default: BUG(); } + + /* + * Require Write permission on the keyring. This is essential + * because the default keyring may be the session keyring, and + * joining a keyring only requires Search permission. + * + * However, this check is skipped for the "requestor keyring" so + * that /sbin/request-key can itself use request_key() to add + * keys to the original requestor's destination keyring. + */ + if (dest_keyring && do_perm_check) { + ret = key_permission(make_key_ref(dest_keyring, 1), + KEY_NEED_WRITE); + if (ret) { + key_put(dest_keyring); + return ret; + } + } } *_dest_keyring = dest_keyring; kleave(" [dk %d]", key_serial(dest_keyring)); - return; + return 0; } /* @@ -442,12 +465,16 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx, if (ctx->index_key.type == &key_type_keyring) return ERR_PTR(-EPERM); - - user = key_user_lookup(current_fsuid()); - if (!user) - return ERR_PTR(-ENOMEM); - construct_get_dest_keyring(&dest_keyring); + ret = construct_get_dest_keyring(&dest_keyring); + if (ret) + goto error; + + user = key_user_lookup(current_fsuid()); + if (!user) { + ret = -ENOMEM; + goto error_put_dest_keyring; + } ret = construct_alloc_key(ctx, dest_keyring, flags, user, &key); key_user_put(user); @@ -462,7 +489,7 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx, } else if (ret == -EINPROGRESS) { ret = 0; } else { - goto couldnt_alloc_key; + goto error_put_dest_keyring; } key_put(dest_keyring); @@ -472,8 +499,9 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx, construction_failed: key_negate_and_link(key, key_negative_timeout, NULL, NULL); key_put(key); -couldnt_alloc_key: +error_put_dest_keyring: key_put(dest_keyring); +error: kleave(" = %d", ret); return ERR_PTR(ret); } -- 2.15.1.504.g5279b80103-goog

7 years

2
1
0 0

[Linux-stable-mirror] [PATCH 1/2 for 3.18/4.1] KEYS: Don't permit request_key() to construct a new keyring

by Eric Biggers

From: David Howells <dhowells(a)redhat.com> commit 911b79cde95c7da0ec02f48105358a36636b7a71 upstream. [Please apply to 3.18-stable and 4.1-stable.] 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 <dhowells(a)redhat.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- security/keys/request_key.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/security/keys/request_key.c b/security/keys/request_key.c index 486ef6fa393b..0d6253124278 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -440,6 +440,9 @@ static struct key *construct_key_and_link(struct keyring_search_context *ctx, kenter(""); + if (ctx->index_key.type == &key_type_keyring) + return ERR_PTR(-EPERM); + user = key_user_lookup(current_fsuid()); if (!user) return ERR_PTR(-ENOMEM); -- 2.15.1.504.g5279b80103-goog

7 years

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2017