Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
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 thefollowing ASSERT() inside scrub_read_endio(): ASSERT(sector_nr < stripe->nr_sectors);Before that, we would have tree dump frombtrfs_get_raid_extent_offset(), as we failed to find the RST entry forthe range.[CAUSE]Inside scrub_submit_extent_sector_read() every time we allocated a newbbio we immediately called btrfs_map_block() to make sure there was someRST 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 findthe sector number (as bi_sector is no longer reliable if the bio issubmitted to lower layers).And since the bio is empty, such bvecs iteration would not find anysector 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, callbtrfs_map_block() first.Since our only objective of calling btrfs_map_block() is only to updatestripe_len, there is really no need to do that after btrfs_alloc_bio().This new timing would avoid the problem of handling empty bbiocompletely, 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, thescrub would never finish (since we didn't decrease the pending_iocounter).Although the root cause of RST lookup failure still needs to beaddressed.
No PoCs from references.
- https://github.com/fkie-cad/nvd-json-data-feeds