CVE-2024-37354: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-37354

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

AI Analysis

Technical Summary

CVE-2024-37354 is a vulnerability in the Linux kernel's Btrfs filesystem implementation. The issue arises from a race condition between the fsync system call and size-extending writes into preallocated extents. Specifically, the bug occurs in the function btrfs_set_item_key_safe() when duplicate keys are encountered during logging of changed extents. This leads to a kernel BUG triggered by overlapping preallocated extent items in the Btrfs tree log, causing a kernel crash. The root cause is that during fsync, the filesystem attempts to split an extent in the log tree, but the split part already exists, triggering an invalid state and a kernel panic. The stack trace shows the crash occurs deep within Btrfs tree logging and extent management code. The vulnerability affects Linux kernel versions prior to the patch that resolves this race condition. Exploitation requires triggering concurrent fsync and size-extending writes on a Btrfs filesystem, which can cause denial of service via kernel crash. No evidence currently exists of active exploitation in the wild. The vulnerability is technical and specific to Btrfs, a copy-on-write filesystem commonly used in Linux environments for its advanced features like snapshots and checksumming.

Potential Impact

For European organizations, the primary impact of CVE-2024-37354 is denial of service (DoS) due to kernel crashes on systems using Btrfs filesystems. This can disrupt critical services, especially in environments relying on Btrfs for data integrity and snapshot capabilities, such as cloud providers, hosting services, and enterprises using Linux servers for storage or virtualization. Data integrity is not directly compromised, but availability is affected as affected systems may crash or reboot unexpectedly. Organizations with automated fsync-heavy workloads or applications performing concurrent writes on Btrfs volumes are at higher risk. The disruption could impact business continuity, leading to downtime and potential financial losses. Since Btrfs is increasingly adopted in enterprise Linux distributions (e.g., SUSE, Fedora, Ubuntu), the scope of affected systems in Europe is significant. However, the lack of known exploits reduces immediate risk, but unpatched systems remain vulnerable to accidental or malicious DoS.

Mitigation Recommendations

1. Apply the official Linux kernel patches that fix the race condition in Btrfs as soon as they become available from trusted sources or distribution vendors. 2. Temporarily avoid workloads that perform concurrent fsync and size-extending writes on Btrfs filesystems until patched. 3. Monitor kernel logs for signs of Btrfs-related crashes or BUG messages indicating this issue. 4. For critical systems, consider using alternative stable filesystems (e.g., ext4, XFS) if Btrfs usage is not mandatory, until patches are applied. 5. Implement robust system monitoring and automated recovery to minimize downtime in case of crashes. 6. Engage with Linux distribution security advisories to track patch availability and deployment status. 7. Test patches in staging environments before production rollout to ensure stability. 8. Educate system administrators on the specific nature of this vulnerability to avoid misdiagnosis of crashes.