Re: CVE-2024-41067: btrfs: scrub: handle RST lookup error correctly

[David Sterba <dsterba@suse.cz>]

On Mon, Jul 29, 2024 at 04:58:13PM +0200, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> btrfs: scrub: handle RST lookup error correctly
> 
> [BUG]
> When running btrfs/060 with forced RST feature, it would crash the
> following ASSERT() inside scrub_read_endio():
> 
> 	ASSERT(sector_nr < stripe->nr_sectors);
> 
> Before that, we would have tree dump from
> btrfs_get_raid_extent_offset(), as we failed to find the RST entry for
> the range.
> 
> [CAUSE]
> Inside scrub_submit_extent_sector_read() every time we allocated a new
> bbio we immediately called btrfs_map_block() to make sure there was some
> RST range covering the scrub target.
> 
> But if btrfs_map_block() fails, we immediately call endio for the bbio,
> while the bbio is newly allocated, it's completely empty.
> 
> Then inside scrub_read_endio(), we go through the bvecs to find
> the sector number (as bi_sector is no longer reliable if the bio is
> submitted to lower layers).
> 
> And since the bio is empty, such bvecs iteration would not find any
> sector matching the sector, and return sector_nr == stripe->nr_sectors,
> triggering the ASSERT().
> 
> [FIX]
> Instead of calling btrfs_map_block() after allocating a new bbio, call
> btrfs_map_block() first.
> 
> Since our only objective of calling btrfs_map_block() is only to update
> stripe_len, there is really no need to do that after btrfs_alloc_bio().
> 
> This new timing would avoid the problem of handling empty bbio
> completely, and in fact fixes a possible race window for the old code,
> where if the submission thread is the only owner of the pending_io, the
> scrub would never finish (since we didn't decrease the pending_io
> counter).
> 
> Although the root cause of RST lookup failure still needs to be
> addressed.
> 
> The Linux kernel CVE team has assigned CVE-2024-41067 to this issue.

Please drop the CVE. It's a fix for feature that's still in development
and is not enabled on production kernels (requires CONFIG_BTRFS_DEBUG).
There was even a recent on-disk format change (mkfs required), this is
not really for environments where security matters. Thanks.