From patchwork Tue Mar 31 17:44:05 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Howells X-Patchwork-Id: 15451 Received: from lists.samba.org (mail.samba.org [66.70.73.150]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n2VHiTNW025992 for ; Tue, 31 Mar 2009 17:44:29 GMT Received: from dp.samba.org (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id A7798163C52 for ; Tue, 31 Mar 2009 17:44:11 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on dp.samba.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.8 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.7 X-Original-To: linux-cifs-client@lists.samba.org Delivered-To: linux-cifs-client@lists.samba.org Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by lists.samba.org (Postfix) with ESMTP id A565E163C0C for ; Tue, 31 Mar 2009 17:43:51 +0000 (GMT) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2VHi8MU022108; Tue, 31 Mar 2009 13:44:08 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2VHi7nt005643; Tue, 31 Mar 2009 13:44:08 -0400 Received: from warthog.cambridge.redhat.com (kibblesnbits.boston.devel.redhat.com [10.16.60.12]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2VHi6eP024587; Tue, 31 Mar 2009 13:44:07 -0400 Received: from [127.0.0.1] (helo=redhat.com) by warthog.cambridge.redhat.com with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1Loi0L-0003pb-9r; Tue, 31 Mar 2009 18:44:05 +0100 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20090331084546.6b24d66e@tleilax.poochiereds.net> References: <20090331084546.6b24d66e@tleilax.poochiereds.net> To: Jeff Layton Date: Tue, 31 Mar 2009 18:44:05 +0100 Message-ID: <14730.1238521445@redhat.com> X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Cc: dhowells@redhat.com, linux-cifs-client@lists.samba.org, linux-kernel@vger.kernel.org Subject: [linux-cifs-client] Re: consistent oops from request_key in 2.6.29 X-BeenThere: linux-cifs-client@lists.samba.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Linux CIFS VFS client List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cifs-client-bounces+patchwork-cifs-client=patchwork.kernel.org@lists.samba.org Errors-To: linux-cifs-client-bounces+patchwork-cifs-client=patchwork.kernel.org@lists.samba.org How about the attached patch? David Tested-by: Jeff Layton --- From: David Howells Subject: [PATCH] KEYS: Handle there being no fallback destination keyring for request_key() 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 --- security/keys/request_key.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/security/keys/request_key.c b/security/keys/request_key.c index 22a3158..03fe63e 100644 --- a/security/keys/request_key.c +++ b/security/keys/request_key.c @@ -311,7 +311,8 @@ static int construct_alloc_key(struct key_type *type, 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 key_type *type, 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));