CVE-2024-35949

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: make sure that WRITTEN is set on all metadata blocks<br /> <br /> We previously would call btrfs_check_leaf() if we had the check<br /> integrity code enabled, which meant that we could only run the extended<br /> leaf checks if we had WRITTEN set on the header flags.<br /> <br /> This leaves a gap in our checking, because we could end up with<br /> corruption on disk where WRITTEN isn&amp;#39;t set on the leaf, and then the<br /> extended leaf checks don&amp;#39;t get run which we rely on to validate all of<br /> the item pointers to make sure we don&amp;#39;t access memory outside of the<br /> extent buffer.<br /> <br /> However, since 732fab95abe2 ("btrfs: check-integrity: remove<br /> CONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer call<br /> btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only<br /> ever call it on blocks that are being written out, and thus have WRITTEN<br /> set, or that are being read in, which should have WRITTEN set.<br /> <br /> Add checks to make sure we have WRITTEN set appropriately, and then make<br /> sure __btrfs_check_leaf() always does the item checking. This will<br /> protect us from file systems that have been corrupted and no longer have<br /> WRITTEN set on some of the blocks.<br /> <br /> This was hit on a crafted image tweaking the WRITTEN bit and reported by<br /> KASAN as out-of-bound access in the eb accessors. The example is a dir<br /> item at the end of an eb.<br /> <br /> [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2<br /> [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f]<br /> [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1<br /> [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0<br /> [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206<br /> [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0<br /> [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748<br /> [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9<br /> [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a<br /> [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8<br /> [2.621] FS: 00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000<br /> [2.621] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0<br /> [2.621] Call Trace:<br /> [2.621] <br /> [2.621] ? show_regs+0x74/0x80<br /> [2.621] ? die_addr+0x46/0xc0<br /> [2.621] ? exc_general_protection+0x161/0x2a0<br /> [2.621] ? asm_exc_general_protection+0x26/0x30<br /> [2.621] ? btrfs_get_16+0x33a/0x6d0<br /> [2.621] ? btrfs_get_16+0x34b/0x6d0<br /> [2.621] ? btrfs_get_16+0x33a/0x6d0<br /> [2.621] ? __pfx_btrfs_get_16+0x10/0x10<br /> [2.621] ? __pfx_mutex_unlock+0x10/0x10<br /> [2.621] btrfs_match_dir_item_name+0x101/0x1a0<br /> [2.621] btrfs_lookup_dir_item+0x1f3/0x280<br /> [2.621] ? __pfx_btrfs_lookup_dir_item+0x10/0x10<br /> [2.621] btrfs_get_tree+0xd25/0x1910<br /> <br /> [ copy more details from report ]