CVE-2022-49079 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone
btrfs_can_activate_zone() can be called with the device_list_mutex already held, which will lead to a deadlock:
insert_dev_extents() // Takes device_list_mutex `-> insert_dev_extent() `-> btrfs_insert_empty_item() `-> btrfs_insert_empty_items() `-> btrfs_search_slot() `-> btrfs_cow_block() `-> __btrfs_cow_block() `-> btrfs_alloc_tree_block() `-> btrfs_reserve_extent() `-> find_free_extent() `-> find_free_extent_update_loop() `-> can_allocate_chunk() `-> btrfs_can_activate_zone() // Takes device_list_mutex again
Instead of using the RCU on fs_devices->device_list we can use fs_devices->alloc_list, protected by the chunk_mutex to traverse the list of active devices.
We are in the chunk allocation thread. The newer chunk allocation happens from the devices in the fs_device->alloc_list protected by the chunk_mutex.
btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list)
Also, a device that reappears after the mount won't join the alloc_list yet and, it will be in the dev_list, which we don't want to consider in the context of the chunk alloc.
[15.166572] WARNING: possible recursive locking detected
[15.167117] 5.17.0-rc6-dennis #79 Not tainted
[15.167487] --------------------------------------------
[15.167733] kworker/u8:3/146 is trying to acquire lock:
[15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs]
[15.167733]
[15.167733] but task is already holding lock:
[15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]
[15.167733]
[15.167733] other info that might help us debug this:
[15.167733] Possible unsafe locking scenario:
[15.167733]
[15.171834] CPU0
[15.171834] ----
[15.171834] lock(&fs_devs->device_list_mutex);
[15.171834] lock(&fs_devs->device_list_mutex);
[15.171834]
[15.171834] *** DEADLOCK ***
[15.171834]
[15.171834] May be due to missing lock nesting notation
[15.171834]
[15.171834] 5 locks held by kworker/u8:3/146:
[15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0
[15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0
[15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs]
[15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]
[15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs]
[15.179641]
[15.179641] stack backtrace:
[15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79
[15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014
[15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]
[15.179641] Call Trace:
[15.179641]
[15.179641] dump_stack_lvl+0x45/0x59
[15.179641] __lock_acquire.cold+0x217/0x2b2
[15.179641] lock_acquire+0xbf/0x2b0
[15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]
[15.183838] __mutex_lock+0x8e/0x970
[15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]
[15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]
[15.183838] ? lock_is_held_type+0xd7/0x130
[15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs]
[15.183838] find_free_extent+0x15a/0x14f0 [btrfs]
[15.183838] ? _raw_spin_unlock+0x24/0x40
[15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs]
[15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs]
[15.
---truncated---
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/15/2025
The vulnerability described in CVE-2022-49079 affects the btrfs file system implementation within the Linux kernel, specifically targeting a deadlock condition that occurs during chunk allocation operations. This issue stems from improper locking mechanisms when traversing device lists during zone management operations. The root cause lies in the btrfs_can_activate_zone() function which attempts to acquire the device_list_mutex while it is already held by another execution path, creating a recursive locking scenario that leads to system hang or crash.
The technical flaw manifests when the chunk allocation thread executes btrfs_can_activate_zone() while already holding the device_list_mutex, resulting in a classic deadlock situation. The call chain demonstrates how insert_dev_extents() acquires device_list_mutex and subsequently calls btrfs_can_activate_zone() which attempts to reacquire the same mutex, creating an impossible circular dependency. This recursive locking pattern violates kernel locking conventions and is classified under CWE-20: Improper Check or Handling of Exceptional Conditions. The vulnerability impacts the btrfs file system's ability to manage storage devices in zoned environments, particularly affecting systems using zoned block devices such as those found in enterprise storage arrays.
The operational impact of this vulnerability extends beyond simple system instability to potentially compromise data availability and system reliability in production environments. When the deadlock occurs, the kernel worker thread responsible for chunk allocation becomes blocked indefinitely, preventing further file system operations and potentially causing complete system unresponsiveness. This scenario is particularly dangerous in high-throughput environments where btrfs is actively managing storage allocations. The issue affects systems running kernel versions that include the problematic btrfs implementation, particularly those utilizing zoned storage capabilities where the chunk allocation process is more complex due to zone management requirements. The vulnerability also aligns with ATT&CK technique T1490: Inhibit System Recovery, as it can prevent normal system recovery operations by blocking critical file system functions.
The fix implemented addresses the core issue by changing the device list traversal mechanism from device_list_mutex-protected RCU lists to using fs_devices->alloc_list which is protected by chunk_mutex. This change ensures that during chunk allocation operations, the system uses the appropriate list that is already protected by the correct mutex, eliminating the recursive locking condition. The solution leverages the existing chunk_mutex protection that is already in place for the chunk allocation thread, making it a more consistent and safer approach. The alloc_list contains only devices that are actively participating in the current allocation process, while the device_list contains all devices including those that may not yet be properly initialized for chunk allocation. This modification follows best practices for kernel development by ensuring proper lock ordering and avoiding recursive locking scenarios. The fix also addresses the specific context where newly appearing devices after mount would be in the dev_list rather than the alloc_list, preventing them from being considered during chunk allocation operations where they might not be ready for such operations.
This vulnerability represents a critical race condition in kernel-level file system management and demonstrates the importance of careful lock management in concurrent systems. The solution effectively resolves the deadlock while maintaining the intended functionality of zone management in btrfs. The fix ensures that the chunk allocation thread operates correctly with appropriate device lists and locking semantics, preventing system crashes and maintaining data integrity. System administrators should update to kernel versions containing this fix, particularly those running btrfs file systems with zoned storage capabilities. The vulnerability highlights the complexity of managing concurrent access in storage subsystems and the need for thorough testing of locking mechanisms in kernel code. Organizations using btrfs in production environments should prioritize this update to avoid potential system instability and data access issues.