On Sun, Mar 5, 2017 at 4:57 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > 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... You can see from the log above that s always empty somehow, so the d_can_lookup check is simply not done. I have not looked at the code, but it's not racy, so should follow from the arguments passed to name_to_handle_at.
