From patchwork Sat Mar 21 14:06:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 6064161 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.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D1D90BF90F for ; Sat, 21 Mar 2015 14:07:09 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B7B1720328 for ; Sat, 21 Mar 2015 14:07:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 99ADE20306 for ; Sat, 21 Mar 2015 14:07:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751362AbbCUOHE (ORCPT ); Sat, 21 Mar 2015 10:07:04 -0400 Received: from mail-yh0-f46.google.com ([209.85.213.46]:33151 "EHLO mail-yh0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbbCUOHD (ORCPT ); Sat, 21 Mar 2015 10:07:03 -0400 Received: by yhpt93 with SMTP id t93so51292941yhp.0 for ; Sat, 21 Mar 2015 07:07:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; bh=uaS35p6BYqKAKYC2/Bq7njj35f6gL9ukvcbwJYMxb1I=; b=fX4k9NyJyV3BdqHU9uzGb52jD9PsBJRZyDyqmxPTdEoXiMXcgnpUElCiy8WBcuQzkZ kJ5cUMeEr89/8C+Riz2XMzEI1PGk2w8grtMQDRtHySYM4KqPwws85ovE0o6demSriZpN rUWq58SHX+BYff90DlCzADDzv7U/GhYmp+S0BI3hlKvKf2ljN1qcrU7SvX8Y5YPK5Shb xWVjBkNr3o4HENqSTUA4PlFncEUjpeVqO/gUi0NEGV4zZbUi2OAHyaBo3xgt5s5+KyuV oVQQSfTuvLW4R/1NoIfL1xymgif/zm5kRMGop0cvDJLBQ4KlslmZZDk3u8e62rxmIOXE HjJw== X-Gm-Message-State: ALoCoQlK7IZQuJKpVoa5YeIrIzlh4gc6CSCZ5NtfUQ5oB1n0FkabQE7stjQO1gN0Pj8Zp1YYT6Od X-Received: by 10.52.137.80 with SMTP id qg16mr20881763vdb.66.1426946821981; Sat, 21 Mar 2015 07:07:01 -0700 (PDT) Received: from tlielax.poochiereds.net ([2606:a000:1105:2091:3a60:77ff:fe93:a95d]) by mx.google.com with ESMTPSA id jr8sm1588100vdb.25.2015.03.21.07.07.01 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Mar 2015 07:07:01 -0700 (PDT) Date: Sat, 21 Mar 2015 10:06:57 -0400 From: Jeff Layton To: Christoph Hellwig Cc: "J. Bruce Fields" , linux-nfs@vger.kernel.org Subject: Re: nfsd use after free in 4.0-rc Message-ID: <20150321100657.32ff0340@tlielax.poochiereds.net> In-Reply-To: <20150316182810.GA4690@infradead.org> References: <20150315125614.GA766@infradead.org> <20150315180811.02847842@tlielax.poochiereds.net> <20150316114648.GA7432@infradead.org> <20150316155845.GC12231@fieldses.org> <20150316182810.GA4690@infradead.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 16 Mar 2015 11:28:10 -0700 Christoph Hellwig wrote: > On Mon, Mar 16, 2015 at 11:58:45AM -0400, J. Bruce Fields wrote: > > > 3240 list_add(&stp->st_perstateowner, &oo->oo_owner.so_stateids); > > > 3241 spin_lock(&fp->fi_lock); > > > 3242 list_add(&stp->st_perfile, &fp->fi_stateids); > > > > I assume you're testing only NFS v4.1? > > Exactly. I'm testing with a version of this patch applied to force 4.1: > > http://git.infradead.org/users/hch/pnfs.git/commitdiff/72ef9b95aaed593ac061bb380bc27ced4fd67b4b I've been using 4.2, fwiw... So far, this bug has turned out to be pretty elusive, I've looked all over the so_count handling and I don't see anywhere that we've got a refcount imbalance. I must be missing something, but it all looks right AFAICT. I've also instrumented the code to look for 0->1 transitions on the so_count, and that hasn't fired. I also looked to see whether Bruce's hunch about the nfsd4_find_existing_open thing might be a problem with the sc_count going 0->1 since we're taking a reference there w/o holding the cl_lock. I haven't seen that happen either. Mostly when I see this bug without memory poisoning enabled, it manifests itself as list corruption in one of the stateowner lists during nfsd4_close. Curiously, the attached patch seems to make that problem go away, but the generic/011 test seems to fail most of the time with this in the log: Cannot chdir out of pid directory: Stale file handle ...but if I turn up poisoning of the nfsd4_openowners slab then I get an oops similar to what HCH is seeing. From ebb095adcc65f596f75b85f54e32591cda5d5cde Mon Sep 17 00:00:00 2001 From: Jeff Layton Date: Sat, 21 Mar 2015 09:20:53 -0400 Subject: [PATCH] nfsd: poison so_owner.data before freeing it Signed-off-by: Jeff Layton --- fs/nfsd/nfs4state.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index d2f2c37dc2db..7ba3fd19caeb 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -913,6 +913,7 @@ static void nfs4_put_stateowner(struct nfs4_stateowner *sop) return; sop->so_ops->so_unhash(sop); spin_unlock(&clp->cl_lock); + memset(sop->so_owner.data, 0x7c, sop->so_owner.len); kfree(sop->so_owner.data); sop->so_ops->so_free(sop); } -- 2.1.0