linux-kernel - Re: [PATCH] ovl: check before dereferencing s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <vtan7uaf5mf35zxy6pma6sdahxr7idv2awaf7yh7vtyhxsoram@2au7ec4hto7i>
Date: Thu, 18 Sep 2025 11:59:14 +0200
From: Jan Kara <jack@...e.cz>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Amir Goldstein <amir73il@...il.com>, Jan Kara <jack@...e.cz>, 
	Jakub Acs <acsjakub@...zon.de>, linux-unionfs@...r.kernel.org, 
	Miklos Szeredi <miklos@...redi.hu>, linux-kernel@...r.kernel.org, stable@...r.kernel.org, 
	Christian Brauner <brauner@...nel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] ovl: check before dereferencing s_root field

On Wed 17-09-25 21:42:00, Al Viro wrote:
> On Wed, Sep 17, 2025 at 01:07:45PM +0200, Amir Goldstein wrote:
> 
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 60046ae23d514..8c9d0d6bb0045 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -1999,10 +1999,12 @@ struct dentry *d_make_root(struct inode *root_inode)
> > 
> >         if (root_inode) {
> >                 res = d_alloc_anon(root_inode->i_sb);
> > -               if (res)
> > +               if (res) {
> > +                       root_inode->i_opflags |= IOP_ROOT;
> >                         d_instantiate(res, root_inode);
> 
> Umm...  Not a good idea - if nothing else, root may end up
> being attached someplace (normal with nfs, for example).
> 
> But more fundamentally, once we are into ->kill_sb(), let alone
> generic_shutdown_super(), nobody should be playing silly buggers
> with the filesystem.  Sure, RCU accesses are possible, but messing
> around with fhandles?  ->s_root is not the only thing that might
> be no longer there.
> 
> What the fuck is fsnotify playing at?

The problem is fsnotify marks aren't shutdown until generic_shutdown_super()
calls fsnotify_sb_delete(). So until that moment fsnotify can be generating
events for the filesystem. Sure, userspace has no longer access to the fs
but stuff like delayed inode deletion or other in-kernel users can still
result in events being generated and these events may end up creating file
handles to report to userspace.

We have already uncovered with Amir quite a few moments how this is broken
so I agree that the best solution is to shutdown fsnotify before we call
shrink_dcache_for_umount(). The slight problem is this means iterating all
inodes in the sb which is costly when you have millions of them (this is
the reason why fsnotify_sb_delete() is currently called after
evict_inodes()). So it needs more work on fsnotify side...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR