Re: [PATCH v3] btrfs: don't access possibly stale fs_info data for printing duplicate device

[David Sterba <dsterba@suse.cz>]

On Wed, Nov 18, 2020 at 05:28:57PM +0800, Anand Jain wrote:
> On 18/11/20 5:03 pm, Johannes Thumshirn wrote:
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -940,7 +940,13 @@ static noinline struct btrfs_device *device_list_add(const char *path,
> >   			if (device->bdev != path_bdev) {
> >   				bdput(path_bdev);
> >   				mutex_unlock(&fs_devices->device_list_mutex);
> > -				btrfs_warn_in_rcu(device->fs_info,
> > +				/*
> > +				 * device->fs_info may not be reliable here, so
> > +				 * pass in a NULL fs_info. This avoids a
> > +				 * possible use-after-free when the fs_info and
> > +				 * fs_info->sb are already torn down.
> > +				 */
> > +				btrfs_warn_in_rcu(NULL,
> >   	"duplicate device %s devid %llu generation %llu scanned by %s (%d)",
> >   						  path, devid, found_transid,
> >   						  current->comm,
> > 
> 
> Few lines below, there is btrfs_info_in_rcu() and, we won't have
> reliable device->fs_info even there. But we have seen those info
> quite a lot of times. And so far, it's been ok. So

Right, this also looks like potentially unsafe use but given that the
2nd print is still under device_list_mutex it think it will be harder
to hit.