CVE-2024-42103 in Linux
Riassunto
di VulDB • 17/06/2026
Based on the kernel log and the analysis provided, here is a breakdown of the issue, the root cause, and the proposed fix.
### 1. Problem Summary A **kernel panic/oops** occurs in the Btrfs filesystem during block group reclamation (`btrfs_delete_unused_bgs`). The crash is triggered by an **invalid opcode exception** (`exc_invalid_op`), likely caused by accessing corrupted or invalid memory structures due to a **race condition** in the block group list management.
The specific crash location is: ``` btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]
``` The call trace shows `__list_del_entry_valid_or_report` being called repeatedly, indicating that the code is trying to delete a list entry that is already corrupted or not properly linked.
### 2. Root Cause Analysis The bug is a **race condition** between: 1. **Block Group Reclamation (`btrfs_delete_unused_bgs`)**: This function iterates over block groups to reclaim space. It moves block groups from the `unused` list to the `reclaim` list if they are eligible. 2. **Block Group Allocation/Deallocation**: Other tasks may be allocating or deallocating extents from block groups, which can move block groups between lists (`unused`, `reclaim`, `free`, etc.).
#### Why the existing code is unsafe: - The code in `btrfs_delete_unused_bgs` checks if a block group is eligible for reclamation by verifying that `used`, `reserved`, and `pinned` bytes are 0. - However, **it does not hold `space_info->groups_sem` in write mode** while iterating and modifying the lists. - This allows other tasks to: - Allocate extents from a block group (moving it out of `unused`). - Deallocate extents (potentially moving it back to `unused` or `reclaim`). - Modify the block group's list pointers concurrently.
#### Why the similar code in `btrfs_delete_unused_bgs` is safe: - The analysis states that a similar retry loop is safe because it holds `space_info->groups_sem` in **write mode**. - This semaphore prevents other tasks from allocating from or deallocating extents from block groups while the reclamation logic is running. - Without this lock, the block group's state can change unexpectedly, leading to list corruption.
### 3. Reproduction - The bug can be reproduced by running the `btrfs/166` test case after a few rounds. - In practice, it is hit when **relocation cannot find more chunk space** and ends with **ENOSPC** (No Space Left on Device). This scenario increases the likelihood of block groups being moved between lists concurrently.
### 4. Proposed Fix The fix should ensure that `btrfs_delete_unused_bgs` holds `space_info->groups_sem` in **write mode** while iterating over and modifying the block group lists. This will prevent other tasks from altering the block group's state or list membership during the reclamation process.
#### Key Changes: 1. **Acquire `space_info->groups_sem` in write mode** before iterating over the block groups. 2. **Release the semaphore** after the reclamation logic is complete. 3. Ensure that all list modifications (moving block groups between `unused`, `reclaim`, etc.) are done while holding this lock.
### 5. Code Patch Example Here is a conceptual patch to illustrate the fix:
```c // In btrfs_delete_unused_bgs()
// Before iterating over block groups down_write(&space_info->groups_sem);
// Iterate over block groups list_for_each_entry_safe(block_group, tmp, &space_info->unused_bgs, list) {
// Check eligibility under the lock if (block_group->used == 0 && block_group->reserved == 0 && block_group->pinned == 0) {
// Move to reclaim list list_move(&block_group->list, &space_info->reclaim_bgs); } }
// After reclamation logic up_write(&space_info->groups_sem); ```
### 6. Verification - Run the `btrfs/166` test case multiple times to ensure the crash no longer occurs. - Monitor for any performance regressions due to the additional locking. - Ensure that block group reclamation still works correctly under high concurrency.
### 7. Conclusion The crash is caused by a race condition in `btrfs_delete_unused_bgs` due to missing write locking on `space_info->groups_sem`. By acquiring this lock in write mode during the reclamation process, the race condition is eliminated, and the list corruption is prevented.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.