CVE-2024-50118

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject ro-&gt;rw reconfiguration if there are hard ro requirements<br /> <br /> [BUG]<br /> Syzbot reports the following crash:<br /> <br /> BTRFS info (device loop0 state MCS): disabling free space tree<br /> BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)<br /> BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline]<br /> RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041<br /> Call Trace:<br /> <br /> btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530<br /> btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312<br /> btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012<br /> btrfs_remount_rw fs/btrfs/super.c:1309 [inline]<br /> btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534<br /> btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline]<br /> btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline]<br /> btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115<br /> vfs_get_tree+0x90/0x2b0 fs/super.c:1800<br /> do_new_mount+0x2be/0xb40 fs/namespace.c:3472<br /> do_mount fs/namespace.c:3812 [inline]<br /> __do_sys_mount fs/namespace.c:4020 [inline]<br /> __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> [CAUSE]<br /> To support mounting different subvolume with different RO/RW flags for<br /> the new mount APIs, btrfs introduced two workaround to support this feature:<br /> <br /> - Skip mount option/feature checks if we are mounting a different<br /> subvolume<br /> <br /> - Reconfigure the fs to RW if the initial mount is RO<br /> <br /> Combining these two, we can have the following sequence:<br /> <br /> - Mount the fs ro,rescue=all,clear_cache,space_cache=v1<br /> rescue=all will mark the fs as hard read-only, so no v2 cache clearing<br /> will happen.<br /> <br /> - Mount a subvolume rw of the same fs.<br /> We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY<br /> because our new fc is RW, different from the original fs.<br /> <br /> Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag<br /> first so that we can grab the existing fs_info.<br /> Then we reconfigure the fs to RW.<br /> <br /> - During reconfiguration, option/features check is skipped<br /> This means we will restart the v2 cache clearing, and convert back to<br /> v1 cache.<br /> This will trigger fs writes, and since the original fs has "rescue=all"<br /> option, it skips the csum tree read.<br /> <br /> And eventually causing NULL pointer dereference in super block<br /> writeback.<br /> <br /> [FIX]<br /> For reconfiguration caused by different subvolume RO/RW flags, ensure we<br /> always run btrfs_check_options() to ensure we have proper hard RO<br /> requirements met.<br /> <br /> In fact the function btrfs_check_options() doesn&amp;#39;t really do many<br /> complex checks, but hard RO requirement and some feature dependency<br /> checks, thus there is no special reason not to do the check for mount<br /> reconfiguration.