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

[Anand Jain <anand.jain@oracle.com>]

On 17/11/20 4:19 pm, Johannes Thumshirn wrote:
> On 17/11/2020 08:20, Anand Jain wrote:
>>    This patch fixes the issue in a very gross way, as I mentioned.
> 
> I know but I've not found a better way.
> 

>>    Instead, do we know more about what/how threads were racing,
>>    leading to the access of the freed fs_info?
> 




> If I read the reproducer code correctly it's just mounting a crafted
> image twice via different /dev/loop devices.
> 
> This image is rejected by the mount code, because it can't read the chunk
> tree.
 >
> As far as I've debugged it down scan_one_device() is racing with
> deactivate_locked_super(), so fs_info->sb can already be freed, when
> device_list_add() calls btrfs_warn_in_rcu(device->fs_info,...) leading
> to a use-after-free in btrfs_printk() accessing fs_info->sb_s_id.
> 

  This explains the problem how it happened, IMO this should go into the
  change log.

> It feels like we're missing a mutex_lock(&uuid_mutex) in btrfs_kill_super()

  Yes.
  But uuid_mutex (or device_list_mutex) is too sever for a simple
  problem, and there are other constraints with device_list_mutex.

  Ok let us take out use of fs_info from the device_list_add().

  I am ok with either NO_FS_INFO approach or just NULL.

Thanks, Anand

> but this hasn't led me to anything.

> 
> I'm all ears for a pointer to the correct fix.
>