Re: [PATCH 0/8] fs: fix a range of UAFs during rcu pathwalk caused by non-rcu frees
flat view
From: Jan Kara <jack@suse.cz>
Date: 2026-10-13 10:48:06
Also in:
linux-ext4, linux-fsdevel, ntfs3, stable, v9fs
On Mon 12-10-26 12:42:06, Christian Brauner wrote:
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 container teardown. I still think in-progress RCU lookups on a sb being unmounted will be a source of bugs in the future (dependencies during fs unmount are complex as is and adding RCU lookups to the game adds even more complexity). Anyway, if we're going to do that then eventually I think we'll need to add something like lockdep context tracking to verify each structure accessed from RCU lookup is properly RCU-freed but that's for later.
Bringing put_super() into the argument was maybe not my best idea. We also need to backport this stuff.
OK, let's go with these fixes for now. Honza -- Jan Kara [off-list ref] SUSE Labs, CR