CVE-2024-41067

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