2.6.29-stable review patch. If anyone has any objections, please let us know. ------------------ From: David Howells commit 34574dd10b6d0697b86703388d6d6af9cbf4bb48 upstream. When request_key() is called, without there being any standard process keyrings on which to fall back if a destination keyring is not specified, an oops is liable to occur when construct_alloc_key() calls down_write() on dest_keyring's semaphore. Due to function inlining this may be seen as an oops in down_write() as called from request_key_and_link(). This situation crops up during boot, where request_key() is called from within the kernel (such as in CIFS mounts) where nobody is actually logged in, and so PAM has not had a chance to create a session keyring and user keyrings to act as the fallback. To fix this, make construct_alloc_key() not attempt to cache a key if there is no fallback key if no destination keyring is given specifically. Signed-off-by: David Howells Tested-by: Jeff Layton Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman --- security/keys/request_key.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -311,7 +311,8 @@ static int construct_alloc_key(struct ke set_bit(KEY_FLAG_USER_CONSTRUCT, &key->flags); - down_write(&dest_keyring->sem); + if (dest_keyring) + down_write(&dest_keyring->sem); /* attach the key to the destination keyring under lock, but we do need * to do another check just in case someone beat us to it whilst we @@ -322,10 +323,12 @@ static int construct_alloc_key(struct ke if (!IS_ERR(key_ref)) goto key_already_present; - __key_link(dest_keyring, key); + if (dest_keyring) + __key_link(dest_keyring, key); mutex_unlock(&key_construction_mutex); - up_write(&dest_keyring->sem); + if (dest_keyring) + up_write(&dest_keyring->sem); mutex_unlock(&user->cons_lock); *_key = key; kleave(" = 0 [%d]", key_serial(key)); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/