From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zeniv.linux.org.uk ([195.92.253.2]:40992 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241AbdCESCy (ORCPT ); Sun, 5 Mar 2017 13:02:54 -0500 Date: Sun, 5 Mar 2017 15:57:07 +0000 From: Al Viro To: Dmitry Vyukov Cc: "linux-fsdevel@vger.kernel.org" , LKML , syzkaller Subject: Re: fs: use-after-free in path_lookupat Message-ID: <20170305155707.GI29622@ZenIV.linux.org.uk> References: <20170304193910.GG29622@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Mar 05, 2017 at 12:37:13PM +0100, Dmitry Vyukov wrote: > I am pretty sure it is that one. > I don't think I ever used name_to_handle_at syscall in my life and I > definitely didn't make it lookup a memfd :) So what does it normally return? On the runs where we do not hit that use-after-free, that is. What gets triggered there is nd->path.dentry pointing to already freed dentry. We are in RCU mode, so we are not pinning the dentry and it might have reached dentry_free(). However, anything with DCACHE_RCUACCESS set would have freeing RCU-delayed, making that impossible. memfd stuff does *not* have DCACHE_RCUACCESS, which would've made it plausible, but... there we really should've been stopped cold by the d_can_lookup() check - that is done while we are still holding a reference to struct file, which should've prevented freeing and reuse. So at the time of that check we have dentry still not reused by anything, and d_can_lookup() should've failed. There is a race that could bugger the things up in that area, but it needs empty name, so this one is something else...