Re: [PATCH 0/8] fs: fix a range of UAFs during rcu pathwalk caused by non-rcu frees

On Tue, Oct 13, 2026 at 09:23:07PM +0200, Christian Brauner wrote:

On Tue, Oct 13, 2026 at 12:47:58PM +0200, Jan Kara wrote:

quoted

On Mon 12-10-26 12:42:06, Christian Brauner wrote:

quoted

On Mon, Oct 12, 2026 at 12:36:15PM +0200, Jan Kara wrote:

quoted

On Fri 09-10-26 23:51:50, Christian Brauner wrote:

quoted

While working on eliding the grace period in namespace_unlock() I went
through what filesystems free when they're shut down and what a pathwalk
in rcu mode can still read at that point. Since 66a97c2ec953's rcu
pathwalk fixes that's the filesystem's job. Whatever ->permission(),
->d_revalidate(), ->get_link(), ->d_hash() and ->d_compare() look at in
rcu mode has to be freed after a grace period. A few filesystems don't
do that.

Most of it is hidden by umount(2). namespace_unlock() waits for a grace
period before it drops the mounts, so a walker that was inside the
filesystem is gone by the time the filesystem is shut down.

But the last reference to a mount doesn't have to go away in umount(2).
A chdir() out of a lazily unmounted directory or the close() of the last
file on it drops it without a grace period. A walker can then still be
in the filesystem while ->put_super() and ->kill_sb() free what it
reads.

Good catches! But I find it very counter-intuitive that pathname lookups
can still be running against a filesystem while its ->put_super is called.
People will keep forgetting about that and as a result these UAF bugs will
be introduced again. Isn't it feasible we'd guarantee to the filesystem
->put_super() gets called only after all lookups are done (i.e., after RCU
grace period expires)?

I understand this is a hairy bussiness because this has userspace visible
implications (like when filesystem's sysfs files disappear, when the bdev
really gets unused, etc.) but keeping all filesystems safe to run RCU
lookup after ->put_super() will be IMHO a headache.

I don't think delaying put_super() or freeing the superblock helps.
That's not where the issue is. The issue is with sb->s_fs_info being
available after a grace period and that can go away in different
locations ->put_super() or ->kill_sb().

So my thinking was: Cannot we separate the teardown of mounts and the
teardown of the sb by an RCU grace period? Then by the time the filesystem
gets to any freeing of filesystem related structures all RCU lookups are
guaranteed to be done so there's no problem with them accessing possibly
freed structures pointed to by the sb.

But then I've read more of the changelogs and AFAIU getting rid of the RCU
grace period waiting in the unmount path is actually your point to speedup

So I prototyped your thing and all version I could see working end up
penalizing umount and filesystem shutdown quite heavily. Maybe I'm not
imagnative enough but everything involving synchronize_rcu* should be
kicked in the n*ts. Because if you're going onto big machines your
workloads will get said kick.

And one thing I forgot to say: that requirement exists today. It is
entirely accidental that this wasn't an issue in the umount() path
because of the synchronize_rcu* in there. But said grace period doesn't
exist if you e.g., chdir() out of a mount and put the last reference
while still in lookup. Then said filesystems are fscked today because
that is a requirement. And various reproducers in this series illustrate
that.