From patchwork Mon Jul 29 00:10:49 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 2834740 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id CC027C0319 for ; Mon, 29 Jul 2013 00:11:10 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C14492011B for ; Mon, 29 Jul 2013 00:11:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7E43200F0 for ; Mon, 29 Jul 2013 00:11:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751498Ab3G2ALH (ORCPT ); Sun, 28 Jul 2013 20:11:07 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:51552 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751485Ab3G2ALF convert rfc822-to-8bit (ORCPT ); Sun, 28 Jul 2013 20:11:05 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1V3b3F-0001wO-2e; Sun, 28 Jul 2013 18:11:01 -0600 Received: from c-98-207-154-105.hsd1.ca.comcast.net ([98.207.154.105] helo=eric-ThinkPad-X220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1V3b3B-0006N0-IZ; Sun, 28 Jul 2013 18:11:00 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Toralf =?utf-8?Q?F=C3=B6rster?= , "Serge E. Hallyn" , Andrey Vagin , Al Viro , Linux NFS mailing list References: <51F39AE8.3090401@gmx.de> <20130727170051.GA31447@redhat.com> Date: Sun, 28 Jul 2013 17:10:49 -0700 In-Reply-To: <20130727170051.GA31447@redhat.com> (Oleg Nesterov's message of "Sat, 27 Jul 2013 19:00:51 +0200") Message-ID: <87iozujkdy.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 X-XM-AID: U2FsdGVkX1+s3L3RoVrg6J1vCzU7YIvMYAwJwZjyU+I= X-SA-Exim-Connect-IP: 98.207.154.105 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Status: No, score=-8.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-DCC: XMission; sa08 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Oleg Nesterov X-Spam-Relay-Country: Subject: Re: fuzz tested user mode linux core dumps in fs/lockd/clntproc.c:131 X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Oleg Nesterov writes: > On 07/27, Toralf Förster wrote: >> >> I do have a user mode linux image (stable 32 bit Gentoo Linux ) which erratically crashes >> while fuzz tested with trinity if the victim files are located on a NFS share. >> >> The back trace of the core dumps always looks like the attached. >> >> To bisect it is hard. However after few attempts in the last weeks the following >> commit is either the first bad commit or at least the upper limit (less likely). >> >> >> commit 8aac62706adaaf0fab02c4327761561c8bda9448 >> Author: Oleg Nesterov >> Date: Fri Jun 14 21:09:49 2013 +0200 >> >> move exit_task_namespaces() outside of exit_notify() >> >> #15 nlmclnt_setlockargs (req=0x48e18860, fl=0x48f27c8c) at fs/lockd/clntproc.c:131 > > Thanks. > > So nlmclnt_setlockargs()->utsname() crashes and we probably need > the patch below. > > But is it correct? I know _absolutely_ nothing about nfs/sunrpc/etc and > I never looked into this code before, most probably I am wrong. > > But it seems that __nlm_async_call() relies on workqueues. > nlmclnt_async_call() does rpc_wait_for_completion_task(), but what if > the caller is killed? > > nlm_rqst can't go away, ->a_count was incremented. But can't the caller > exit before call->name is used? In this case the memory it points to > can be already freed. I don't think anyone has ever looked into that. This was a flyby conversion by Serge in 2006 when he originally did the uts namespace. from commit e9ff3990f08e9a0c2839cc22808b01732ea5b3e4 [PATCH] namespaces: utsname: switch to using uts namespaces Replace references to system_utsname to the per-process uts namespace where appropriate. This includes things like uname. Changes: Per Eric Biederman's comments, use the per-process uts namespace for ELF_PLATFORM, sunrpc, and parts of net/ipv4/ipconfig.c Hmm. That credits with me with this mess. What was I thinking? Perhaps I just said you missed a couple of spots. This untested patch should fix it without any need to worry about dynamic behavior. Although I am wondering if we have a few other spots where the dynamic behavior might be iffy. Serge do you remember any of this? On a good day I can follow the nfs code but it takes quite a while. I feel the same way about filesystems locks so I am not really certain what is going on. Eric Eric --- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c index 9760ecb..6643cfc 100644 --- a/fs/lockd/clntproc.c +++ b/fs/lockd/clntproc.c @@ -128,11 +128,11 @@ static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl) nlmclnt_next_cookie(&argp->cookie); memcpy(&lock->fh, NFS_FH(file_inode(fl->fl_file)), sizeof(struct nfs_fh)); - lock->caller = utsname()->nodename; + lock->caller = init_utsname()->nodename; lock->oh.data = req->a_owner; lock->oh.len = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s", (unsigned int)fl->fl_u.nfs_fl.owner->pid, - utsname()->nodename); + init_utsname()->nodename); lock->svid = fl->fl_u.nfs_fl.owner->pid; lock->fl.fl_start = fl->fl_start; lock->fl.fl_end = fl->fl_end;