CVE-2024-35784 in Linux
Summary
by MITRE • 05/17/2024
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock with fiemap and extent locking
While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock.
This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it.
Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace
[] lock_extent+0x28d/0x2f0
[] btrfs_page_mkwrite+0x273/0x8a0
[] do_page_mkwrite+0x50/0xb0
[] do_fault+0xc1/0x7b0
[] __handle_mm_fault+0x2fa/0x460
[] handle_mm_fault+0xa4/0x330
[] do_user_addr_fault+0x1f4/0x800
[] exc_page_fault+0x7c/0x1e0
[] asm_exc_page_fault+0x26/0x30
[] rep_movs_alternative+0x33/0x70
[] _copy_to_user+0x49/0x70
[] fiemap_fill_next_extent+0xc8/0x120
[] emit_fiemap_extent+0x4d/0xa0
[] extent_fiemap+0x7f8/0xad0
[] btrfs_fiemap+0x49/0x80
[] __x64_sys_ioctl+0x3e1/0xb50
[] do_syscall_64+0x94/0x1a0
[] entry_SYSCALL_64_after_hwframe+0x6e/0x76
I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking.
To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before.
The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag.
With this patch applied we no longer deadlock with my testcase.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/21/2025
This vulnerability exists within the Linux kernel's btrfs file system implementation and represents a critical deadlock condition that can occur during fiemap operations combined with extent locking mechanisms. The issue manifests when the fiemap ioctl command attempts to enumerate file extents while holding extent locks for extended periods, creating a circular dependency that prevents proper execution flow. The deadlock specifically occurs when a page fault condition triggers during user space copying operations, causing the system to attempt to acquire locks that are already held by other processes in the call stack. This represents a classic deadlock scenario where the kernel's locking subsystem becomes trapped in an inconsistent state.
The technical flaw stems from improper lock management during fiemap operations where the extent lock is held for the entire duration of the fiemap processing cycle. When the fiemap function copies extent information to user space through functions like fiemap_fill_next_extent, page fault exceptions can occur during memory copying operations. The kernel's current implementation holds the extent lock across these potentially blocking operations, creating an opportunity for deadlocks when other threads attempt to acquire the same locks in different orders. This design flaw was previously masked by the absence of lockdep annotations that would have detected the problematic locking patterns during normal operation.
The operational impact of this vulnerability is significant as it can cause complete system hangs or unresponsive file system operations when applications attempt to query file extent information through fiemap. This affects any application that relies on fiemap functionality to understand file layout, including backup utilities, disk analysis tools, and file system management applications. The deadlock condition specifically occurs during memory management operations when page faults are triggered during user space data copying, making it particularly problematic in memory-constrained environments or systems with heavy I/O workloads. This vulnerability can also affect automated systems that perform regular file system analysis or monitoring operations.
The fix implemented addresses this issue by modifying the fiemap implementation to release extent locks during the user space copying phases of the operation. This approach maintains data consistency while avoiding the circular locking dependency that caused the deadlock. The solution preserves necessary locking for delalloc operations where consistency is critical, but removes locks during the non-critical extent enumeration phases. This change aligns with security best practices for lock management and follows the principle of holding locks for minimal durations to prevent deadlocks and improve system responsiveness. The patch has been validated through specific test cases that reproduce the original deadlock conditions, confirming that the fix resolves the problematic locking behavior without compromising data integrity or system functionality. This vulnerability classifies under CWE-362 for concurrent execution using shared resource access and relates to ATT&CK technique T1485 for data destruction through system resource manipulation.