In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid NULL pointer dereference if no valid csum tree
[BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfslookupcsumsbitmap+0x49/0x480 [btrfs] Call Trace: <TASK> scrubfindfillfirststripe+0x35b/0x3d0 [btrfs] scrubsimplemirror+0x175/0x290 [btrfs] scrubstripe+0x5f7/0x6f0 [btrfs] scrubchunk+0x9a/0x150 [btrfs] scrubenumeratechunks+0x333/0x660 [btrfs] btrfsscrubdev+0x23e/0x600 [btrfs] btrfsioctl+0x1dcf/0x2f80 [btrfs] _x64sysioctl+0x97/0xc0 dosyscall64+0x4f/0x120 entrySYSCALL64afterhwframe+0x76/0x7e
[CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification.
Normally call sites utilizing csum tree will check the fs state flag NODATACSUMS bit, but unfortunately scrub does not check that bit at all.
This results in scrub to call btrfssearchslot() on a NULL pointer and triggered above crash.
[FIX] Check both extent and csum tree root before doing any tree search.