Re: [PATCH -v3] ext4: fix use-after-free race in ext4_remount()'s error path

[Jan Kara <jack@suse.cz>]

On Thu 11-10-18 08:29:53, Paul E. McKenney wrote:
> On Thu, Oct 11, 2018 at 12:28:00PM +0200, Jan Kara wrote:
> > On Sat 06-10-18 23:07:06, Theodore Ts'o wrote:
> > > It's possible for ext4_show_quota_options() to try reading
> > > s_qf_names[i] while it is being modified by ext4_remount() --- most
> > > notably, in ext4_remount's error path when the original values of the
> > > quota file name gets restored.
> > > 
> > > Reported-by: syzbot+a2872d6feea6918008a9@syzkaller.appspotmail.com
> > > Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> > > Cc: stable@kernel.org
> > 
> > Well, honestly the fact that ->show_options can be called while remount is
> > changing stuff under you looks problematic to me and I bet ext4 is not the
> > only one that would have issues with that. So I believe we might be better
> > off with just synchronizing ->show_options with umount / remount properly.
> > What were the lock dependency problems that made you switch to use RCU?
> 
> OK, I will bite...
> 
> Ted's patch does in fact just properly synchronize ->show_options with
> umount / remount.  Using RCU.  ;-)

Well, it does but only for quota mount options. There may be other mount
options which would need similar treatment and possibly other mount options
in other filesystems. So I think a saner VFS API would be to synchronize
->show_options with umount / remount so that each filesystem does not have
to do it on its own.

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