From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
joel@joelfernandes.org, Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH -v3] ext4: fix use-after-free race in ext4_remount()'s error path
Date: Thu, 11 Oct 2018 10:20:10 -0700 [thread overview]
Message-ID: <20181011172010.GM2674@linux.ibm.com> (raw)
In-Reply-To: <20181011164854.GA29637@quack2.suse.cz>
On Thu, Oct 11, 2018 at 06:48:54PM +0200, Jan Kara wrote:
> 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.
On that choice, I must of course defer to the various filesystem and
VFS people, yourself included.
Thanx, Paul
next prev parent reply other threads:[~2018-10-12 0:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-07 3:07 [PATCH -v3] ext4: fix use-after-free race in ext4_remount()'s error path Theodore Ts'o
2018-10-09 5:30 ` Paul E. McKenney
2018-10-11 10:28 ` Jan Kara
2018-10-11 15:29 ` Paul E. McKenney
2018-10-11 16:48 ` Jan Kara
2018-10-11 17:20 ` Paul E. McKenney [this message]
2018-10-11 19:02 ` Theodore Y. Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181011172010.GM2674@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=jack@suse.cz \
--cc=joel@joelfernandes.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.