Qu Wenruo 642b9c520e btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned
commit f546c4282673497a06ecb6190b50ae7f6c85b02f upstream.

[BUG]
There is a bug report that, on a ext4-converted btrfs, scrub leads to
various problems, including:

- "unable to find chunk map" errors
  BTRFS info (device vdb): scrub: started on devid 1
  BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096
  BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056

  This would lead to unrepariable errors.

- Use-after-free KASAN reports:
  ==================================================================
  BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0
  Read of size 8 at addr ffff8881013c9040 by task btrfs/909
  CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023
  Call Trace:
   <TASK>
   dump_stack_lvl+0x43/0x60
   print_report+0xcf/0x640
   kasan_report+0xa6/0xd0
   __blk_rq_map_sg+0x18f/0x7c0
   virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]
   virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]
   blk_mq_flush_plug_list.part.0+0x780/0x860
   __blk_flush_plug+0x1ba/0x220
   blk_finish_plug+0x3b/0x60
   submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
   flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
   scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
   scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
   scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
   btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
   btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]
   __x64_sys_ioctl+0xbd/0x100
   do_syscall_64+0x5d/0xe0
   entry_SYSCALL_64_after_hwframe+0x63/0x6b
  RIP: 0033:0x7f47e5e0952b

- Crash, mostly due to above use-after-free

[CAUSE]
The converted fs has the following data chunk layout:

    item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80
        length 86016 owner 2 stripe_len 65536 type DATA|single

For above logical bytenr 2214744064, it's at the chunk end
(2214658048 + 86016 = 2214744064).

This means btrfs_submit_bio() would split the bio, and trigger endio
function for both of the two halves.

However scrub_submit_initial_read() would only expect the endio function
to be called once, not any more.
This means the first endio function would already free the bbio::bio,
leaving the bvec freed, thus the 2nd endio call would lead to
use-after-free.

[FIX]
- Make sure scrub_read_endio() only updates bits in its range
  Since we may read less than 64K at the end of the chunk, we should not
  touch the bits beyond chunk boundary.

- Make sure scrub_submit_initial_read() only to read the chunk range
  This is done by calculating the real number of sectors we need to
  read, and add sector-by-sector to the bio.

Thankfully the scrub read repair path won't need extra fixes:

- scrub_stripe_submit_repair_read()
  With above fixes, we won't update error bit for range beyond chunk,
  thus scrub_stripe_submit_repair_read() should never submit any read
  beyond the chunk.

Reported-by: Rongrong <i@rong.moe>
Fixes: e02ee89baa66 ("btrfs: scrub: switch scrub_simple_mirror() to scrub_stripe infrastructure")
Tested-by: Rongrong <i@rong.moe>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[ Use min_t() to fix a compiling error due to difference types ]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-31 16:19:05 -08:00
..
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-28 11:39:14 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-28 09:31:32 -07:00
2023-08-28 11:04:18 -07:00
2023-08-28 10:17:14 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 17:45:22 -04:00
2023-08-29 20:21:42 -07:00
2024-01-15 18:57:06 +01:00
2023-08-31 12:07:34 -05:00
2023-08-29 20:21:42 -07:00
2023-10-19 09:10:18 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
\n
2023-08-30 12:10:50 -07:00
2023-08-29 20:21:42 -07:00
2023-08-28 09:31:32 -07:00
2023-08-28 11:59:52 -07:00
2023-08-28 10:17:14 -07:00
2023-06-28 20:35:21 -07:00
2023-06-26 09:50:21 -07:00
2023-07-26 14:56:07 +02:00
2023-08-08 19:36:51 +02:00
2023-08-28 10:17:14 -07:00
2023-08-21 13:46:25 -07:00
2023-08-14 18:48:02 +02:00
2023-08-29 20:21:42 -07:00
2023-08-29 20:21:42 -07:00
2023-08-19 12:12:12 +02:00
2023-08-31 15:32:18 -07:00
2023-08-02 09:13:09 -06:00
2023-07-13 10:28:04 +02:00
2023-08-15 08:32:45 +02:00
2023-08-31 12:47:15 +02:00