From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 6 Aug 2018 14:01:47 +0100 From: Al Viro To: "Dae R. Jeong" Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu Subject: Re: KASAN: use-after-free Read in link_path_walk Message-ID: <20180806130147.GL15082@ZenIV.linux.org.uk> References: <20180724034542.GA19283@dragonet> <20180724051726.GH30522@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180724051726.GH30522@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Tue, Jul 24, 2018 at 06:17:26AM +0100, Al Viro wrote: > Do we have LOOKUP_RCU in nd->flags at that point? And how in hell > did we get that dentry there? In LOOKUP_RCU mode no freeing should > be happening until after we call rcu_read_unlock(), unless the final > dput() has happened before rcu_read_lock(). In which case we shouldn't > have gotten to that dentry in the first place. ... except that we never set DCACHE_RCUACCESS for root dentry. Which invalidates the normal "if we run into dentry in lazy mode, its memory won't be freed until we drop rcu_read_lock"... d_make_root() definitely needs to set DCACHE_RCUACCESS; whether it's all there is or you are hitting something else is a separate question, of course... > And in non-LOOKUP_RCU > mode we are bloody well holding references to everything (vfsmount > and dentry alike), so that deactivate_super() shouldn't have been > called as long as we are holding that reference. > > Details, please. Ideally - how to reproduce that. Is there any way to tell KASAN that we want a crashdump triggered? That would've been really useful for post-mortems...