In the Linux kernel, the following vulnerability has been resolved:

btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned

[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 _blkrqmapsg+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> dumpstacklvl+0x43/0x60 printreport+0xcf/0x640 kasanreport+0xa6/0xd0 _blkrqmapsg+0x18f/0x7c0 virtblkpreprq.isra.0+0x215/0x6a0 [virtioblk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] virtioqueuerqs+0xc4/0x310 [virtioblk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff] blkmqflushpluglist.part.0+0x780/0x860 _blkflushplug+0x1ba/0x220 blkfinishplug+0x3b/0x60 submitinitialgroupread+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] flushscrubstripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrubstripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrubchunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] scrubenumeratechunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfsscrubdev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] btrfsioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965] _x64sysioctl+0xbd/0x100 dosyscall64+0x5d/0xe0 entrySYSCALL64afterhwframe+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 btrfssubmitbio() would split the bio, and trigger endio function for both of the two halves.

However scrubsubmitinitial_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 scrubreadendio() 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 scrubsubmitinitial_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:

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