Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1640439yba; Tue, 2 Apr 2019 12:49:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqx8IrLn3rKkV2JoE5fokEBaG+H4AyJLJZffOMBIL2FOKmQFKuW6jlItkMdf8BvS/f9e/Bq0 X-Received: by 2002:a17:902:2ac3:: with SMTP id j61mr72159393plb.112.1554234547791; Tue, 02 Apr 2019 12:49:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554234547; cv=none; d=google.com; s=arc-20160816; b=THBBLW198NW0mChSJxWgBrM5KSbV6nPMSTkKnV6T1M6PfKfK/XycanMh284uo2n9je MLcHjq1Wbmnc4aj6DJaJnQ6CF5jNT6hCHW9miBcaJrIvMa08J7wDHuqH0LJkHnnXtyeh q3LsoTqAmN1GvwLet/c4Sz7oMnWOAHlIcjvi+LuCLGJFyi7NRyIR/Jrxiz9TJNrPM3WY aXfDRT+/WiENszYeZxElYDqN5wR3oZ1Fmu9OZtL/KrWJiki6MpICSHsZWXguYeLMgjVH VwoTKu6KjkiE+Mn+g6k+mXSCcPtV007YUYRAnZjNOczBfRGdZCsy/nkeokJA1A1YxTeE ihFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=KLBFKdeyWV8jKXmDS1Nd4OnNOdrmkX7nOP34LFwlBU4=; b=okMBn2EZmj+Dj/OnW1wbKRgf6M+3OwMGU1ovbZXW5TDie3NCnOOKjeTfSN7VBFe8pT L6RzN7lEzak28jAHT+C3YzWss6tHzx/7ak/4xyILD6h1sM1sFMefQ0Pe86CI2EdkyXZG h2XsWsGRwBA5LAKWLMmKgv/SxX9gA/Le6Qfp9hIcLto9dowyBRctCQNjvcRzT3rLlqEL UV3dtzXMaasqd6+w6jtfXdNg5dMpNW637jasC/MN9xYq/6T9aHeN+nraEIiWIRIfIsrK Fs/a6R/PXYhPCT7DHM7kVhlNqvcDQEnDA3lHRs8GHED71MkCM0GmJxuNDsMQ9Oh7wD7p yyDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w7si10279672pgs.230.2019.04.02.12.48.52; Tue, 02 Apr 2019 12:49:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730220AbfDBTIX (ORCPT + 99 others); Tue, 2 Apr 2019 15:08:23 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:46910 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726083AbfDBTIX (ORCPT ); Tue, 2 Apr 2019 15:08:23 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92 #3 (Red Hat Linux)) id 1hBOlY-0007GR-23; Tue, 02 Apr 2019 19:08:12 +0000 Date: Tue, 2 Apr 2019 20:08:12 +0100 From: Al Viro To: Jonathan Corbet Cc: "Tobin C. Harding" , Mauro Carvalho Chehab , Neil Brown , Randy Dunlap , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Ian Kent Subject: Re: [PATCH v3 00/24] Convert vfs.txt to vfs.rst Message-ID: <20190402190811.GM2217@ZenIV.linux.org.uk> References: <20190327051717.23225-1-tobin@kernel.org> <20190402094934.5b242dc0@lwn.net> <20190402164824.GK2217@ZenIV.linux.org.uk> <20190402175401.GL2217@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190402175401.GL2217@ZenIV.linux.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 02, 2019 at 06:54:01PM +0100, Al Viro wrote: > static void autofs_dentry_release(struct dentry *de) > { > struct autofs_info *ino = autofs_dentry_ino(de); > struct autofs_sb_info *sbi = autofs_sbi(de->d_sb); > > pr_debug("releasing %p\n", de); > > if (!ino) > return; > ... > autofs_free_ino(ino); > } > with autofs_free_ino() being straight kfree(). Which means > that the lockless case of autofs_d_manage() can run into > autofs_dentry_ino(dentry) getting freed right under it. > > And there we do have this reachable: > int autofs_expire_wait(const struct path *path, int rcu_walk) > { > struct dentry *dentry = path->dentry; > struct autofs_sb_info *sbi = autofs_sbi(dentry->d_sb); > struct autofs_info *ino = autofs_dentry_ino(dentry); > int status; > int state; > > /* Block on any pending expire */ > if (!(ino->flags & AUTOFS_INF_WANT_EXPIRE)) > return 0; > if (rcu_walk) > return -ECHILD; > > the second check buggers off in lockless mode; the first one > can be done in lockless mode just fine, so AFAICS we do have > a problem there. Smells like we ought to make that kfree > in autofs_free_ino() RCU-delayed... Ian, have you, by any > chance, run into reports like that? Use-after-free or > oopsen in autofs_expire_wait() and friends, that is... Alternatively, we could clear ->d_fsdata in autofs_d_release() under ->d_lock and have all potentially lockless users of autofs_dentry_ino() take ->d_lock around messing with that. I'd still prefer to do it as below, though. Ian, do you have any objections against the following and, if you are OK with it, which tree would you prefer it to go through? autofs: fix use-after-free in lockless ->d_manage() autofs_d_release() can overlap with lockless ->d_manage(), ending up with autofs_dentry_ino() freed under the latter. Make freeing autofs_info instances RCU-delayed... Signed-off-by: Al Viro --- diff --git a/fs/autofs/autofs_i.h b/fs/autofs/autofs_i.h index 70c132acdab1..e1091312abe1 100644 --- a/fs/autofs/autofs_i.h +++ b/fs/autofs/autofs_i.h @@ -71,6 +71,7 @@ struct autofs_info { kuid_t uid; kgid_t gid; + struct rcu_head rcu; }; #define AUTOFS_INF_EXPIRING (1<<0) /* dentry in the process of expiring */ diff --git a/fs/autofs/inode.c b/fs/autofs/inode.c index 80597b88718b..fb0225f21c12 100644 --- a/fs/autofs/inode.c +++ b/fs/autofs/inode.c @@ -36,7 +36,7 @@ void autofs_clean_ino(struct autofs_info *ino) void autofs_free_ino(struct autofs_info *ino) { - kfree(ino); + kfree_rcu(ino, rcu); } void autofs_kill_sb(struct super_block *sb)