CVE-2022-49702 in Linux
Sumário
de VulDB • 06/08/2026
Based on the stack trace and the explanation provided, this is a **deadlock or hang scenario in Btrfs during filesystem unmount (`close_ctree`)**. The issue arises from a race condition between asynchronous cleanup tasks (space reclaim, block group relocation) and the synchronous shutdown process.
### Root Cause Analysis
The core problem is described as follows:
1. **Shutdown Initiation**: `close_ctree()` begins executing to shut down the Btrfs filesystem. 2. **Parked Cleaner Thread**: The cleaner kthread (responsible for background tasks like space reclaim) is parked/stopped by `close_ctree()`. 3. **Async Reclaim Task Still Running**: However, an *async* metadata/data space reclaim task was already running before the park and continues execution in a different context (likely via workqueues or delayed calls). 4. **Delayed Iput Accumulation**: This async task reaches `flush_space()`, which processes "delayed iputs" (reference count decrements for files that are being freed but deferred to avoid holding locks during heavy operations). 5. **Race Condition with Block Group Relocation**: Simultaneously, an *async block group reclaim* task is relocating a data block group. During relocation (`replace_file_extents()`), it creates new delayed iputs because old file extent items are being replaced/COWed. 6. **The Hang/Deadlock**: The async space reclaim task calls `btrfs_wait_on_delayed_iputs()`. This function waits for *all* pending delayed iputs to complete. However, the block group relocation task (which created new delayed iputs) might be blocked waiting for resources or locks that are held by the shutdown process, or it simply hasn't finished processing its own iputs yet. Since `close_ctree()` has parked the cleaner thread and is trying to finalize unmounts synchronously, but async tasks are still creating/waiting on work items, a circular dependency or indefinite wait occurs.
### Why This Happens in Btrfs
Btrfs uses **delayed iputs** extensively to improve performance by batching reference count updates. During normal operation, the cleaner kthread processes these asynchronously. However, during unmount (`close_ctree()`), the filesystem must ensure all references are dropped and all metadata is consistent before returning control to userspace.
The bug occurs because: - The shutdown path assumes that parking the cleaner thread stops *all* background work. - In reality, async tasks (like space reclaim triggered by previous operations) can still be running in their own contexts after the main cleaner kthread is parked. - These lingering async tasks continue to generate and wait on delayed iputs, which `close_ctree()` cannot safely proceed past until they are resolved. But since the system is shutting down, progress may stall if those tasks depend on resources no longer available or locked by the shutdown sequence.
### Solution / Patch Strategy
To fix this, Btrfs needs to ensure that **all** async work related to delayed iputs and space reclaim is fully completed *before* `close_ctree()` proceeds with unmounting. Key steps include:
1. **Wait for All Async Tasks**: Before parking the cleaner kthread in `close_ctree()`, explicitly wait for any running async space reclamation tasks (both metadata/data) to complete their current work, including flushing all delayed iputs they have initiated or are waiting on. 2. **Flush Delayed Iputs Explicitly**: Ensure that `btrfs_wait_on_delayed_iputs()` is called in a context where no new delayed iputs can be created by async relocation tasks. This might require stopping block group relocations earlier in the shutdown sequence. 3. **Synchronize Relocation Tasks**: Make sure all active block group relocations are finished and their associated delayed iputs processed before entering the final stages of `close_ctree()`.
### Example Fix Concept (Conceptual Code)
In `fs/btrfs/tree-log.c` or similar shutdown-related files, modify `close_ctree()` to:
```c void close_ctree(struct btrfs_fs_info *fs_info) {
// ... existing code ...
/* NEW: Wait for all async space reclamation tasks to finish */ btrfs_wait_space_reclaim_tasks(fs_info);
/* NEW: Ensure no new delayed iputs are being created by relocation */ btrfs_stop_all_workers(fs_info, true); // Stop even more aggressively than just cleaner
/* Park the cleaner kthread (existing step) */ btrfs_park_kthreads(fs_info);
/* Now it's safe to proceed with unmounting since all async work is done */ // ... rest of close_ctree() ... } ```
Additionally, `btrfs_wait_space_reclaim_tasks()` would need to be implemented to wait on completion flags or completions set by the async reclaim tasks
If you want to get the best quality for vulnerability data then you always have to consider VulDB.