CVE-2024-37354

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix crash on racing fsync and size-extending write into prealloc<br /> <br /> We have been seeing crashes on duplicate keys in<br /> btrfs_set_item_key_safe():<br /> <br /> BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/ctree.c:2620!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]<br /> <br /> With the following stack trace:<br /> <br /> #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)<br /> #1 btrfs_drop_extents (fs/btrfs/file.c:411:4)<br /> #2 log_one_extent (fs/btrfs/tree-log.c:4732:9)<br /> #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)<br /> #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)<br /> #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)<br /> #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)<br /> #7 btrfs_sync_file (fs/btrfs/file.c:1933:8)<br /> #8 vfs_fsync_range (fs/sync.c:188:9)<br /> #9 vfs_fsync (fs/sync.c:202:9)<br /> #10 do_fsync (fs/sync.c:212:9)<br /> #11 __do_sys_fdatasync (fs/sync.c:225:9)<br /> #12 __se_sys_fdatasync (fs/sync.c:223:1)<br /> #13 __x64_sys_fdatasync (fs/sync.c:223:1)<br /> #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)<br /> #15 do_syscall_64 (arch/x86/entry/common.c:83:7)<br /> #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)<br /> <br /> So we&amp;#39;re logging a changed extent from fsync, which is splitting an<br /> extent in the log tree. But this split part already exists in the tree,<br /> triggering the BUG().<br /> <br /> This is the state of the log tree at the time of the crash, dumped with<br /> drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)<br /> to get more details than btrfs_print_leaf() gives us:<br /> <br /> &gt;&gt;&gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])<br /> leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610<br /> leaf 33439744 flags 0x100000000000000<br /> fs uuid e5bd3946-400c-4223-8923-190ef1f18677<br /> chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da<br /> item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160<br /> generation 7 transid 9 size 8192 nbytes 8473563889606862198<br /> block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0<br /> sequence 204 flags 0x10(PREALLOC)<br /> atime 1716417703.220000000 (2024-05-22 15:41:43)<br /> ctime 1716417704.983333333 (2024-05-22 15:41:44)<br /> mtime 1716417704.983333333 (2024-05-22 15:41:44)<br /> otime 17592186044416.000000000 (559444-03-08 01:40:16)<br /> item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13<br /> index 195 namelen 3 name: 193<br /> item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37<br /> location key (0 UNKNOWN.0 0) type XATTR<br /> transid 7 data_len 1 name_len 6<br /> name: user.a<br /> data a<br /> item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53<br /> generation 9 type 1 (regular)<br /> extent data disk byte 303144960 nr 12288<br /> extent data offset 0 nr 4096 ram 12288<br /> extent compression 0 (none)<br /> item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53<br /> generation 9 type 2 (prealloc)<br /> prealloc data disk byte 303144960 nr 12288<br /> prealloc data offset 4096 nr 8192<br /> item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53<br /> generation 9 type 2 (prealloc)<br /> prealloc data disk byte 303144960 nr 12288<br /> prealloc data offset 8192 nr 4096<br /> ...<br /> <br /> So the real problem happened earlier: notice that items 4 (4k-12k) and 5<br /> (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and<br /> item 5 starts at i_size.<br /> <br /> Here is the state of <br /> ---truncated---