CVE-2024-42103 in Linux
Summary
by MITRE • 07/30/2024
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix adding block group to a reclaim list and the unused list during reclaim
There is a potential parallel list adding for retrying in btrfs_reclaim_bgs_work and adding to the unused list. Since the block group is removed from the reclaim list and it is on a relocation work, it can be added into the unused list in parallel. When that happens, adding it to the reclaim list will corrupt the list head and trigger list corruption like below.
Fix it by taking fs_info->unused_bgs_lock.
[177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104
[177.514][T2585409] list_del corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0)
[177.529][T2585409] ------------[ cut here ]------------
[177.537][T2585409] kernel BUG at lib/list_debug.c:65!
[177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
[177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G W 6.10.0-rc5-kts #1
[177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022
[177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs]
[177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72
[177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286
[177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000
[177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40
[177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08
[177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0
[177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000
[177.687][T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000
[177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0
[177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000
[177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400
[177.742][T2585409] PKRU: 55555554
[177.748][T2585409] Call Trace:
[177.753][T2585409]
[177.759][T2585409] ? __die_body.cold+0x19/0x27
[177.766][T2585409] ? die+0x2e/0x50
[177.772][T2585409] ? do_trap+0x1ea/0x2d0
[177.779][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72
[177.788][T2585409] ? do_error_trap+0xa3/0x160
[177.795][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72
[177.805][T2585409] ? handle_invalid_op+0x2c/0x40
[177.812][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72
[177.820][T2585409] ? exc_invalid_op+0x2d/0x40
[177.827][T2585409] ? asm_exc_invalid_op+0x1a/0x20
[177.834][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72
[177.843][T2585409] btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]
There is a similar retry_list code in btrfs_delete_unused_bgs(), but it is safe, AFAICS. Since the block group was in the unused list, the used bytes should be 0 when it was added to the unused list. Then, it checks block_group->{used,reserved,pinned} are still 0 under the
block_group->lock. So, they should be still eligible for the unused list, not the reclaim list.
The reason it is safe there it's because because we're holding space_info->groups_sem in write mode.
That means no other task can allocate from the block group, so while we are at deleted_unused_bgs() it's not possible for other tasks to allocate and deallocate extents from the block group, so it can't be added to the unused list or the reclaim list by anyone else.
The bug can be reproduced by btrfs/166 after a few rounds. In practice this can be hit when relocation cannot find more chunk space and ends with ENOSPC.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/26/2025
The vulnerability described in CVE-2024-42103 affects the btrfs file system implementation within the Linux kernel, specifically during the process of reclaiming block groups. This issue arises from a race condition that occurs when multiple threads attempt to manipulate the same block group's list membership concurrently. The kernel's btrfs subsystem maintains lists of block groups that are either in use, pending reclaim, or unused, and these lists are managed through linked structures that must remain consistent to prevent memory corruption.
The flaw manifests when a block group is simultaneously removed from the reclaim list and added to the unused list during a relocation operation. This parallel modification of the same list node causes corruption of the list head, resulting in a kernel panic and system instability. The error trace indicates that the corruption occurs in the list deletion mechanism, specifically within lib/list_debug.c, where the kernel detects an invalid list structure and triggers a BUG() condition.
This vulnerability is classified as a concurrency issue that directly relates to CWE-362, which describes a race condition in which two or more threads access shared data concurrently, and at least one of the accesses is a write operation. The root cause stems from insufficient synchronization during the manipulation of shared data structures. The fix implemented in the kernel involves acquiring the fs_info->unused_bgs_lock, which provides mutual exclusion around the operations that modify the unused block group lists, thereby preventing the concurrent access that leads to corruption.
The operational impact of this vulnerability is significant, as it can lead to system crashes and data corruption in environments utilizing btrfs file systems. The issue is particularly problematic during high I/O workloads where relocation operations are frequent and the system is under memory pressure. The reproduction scenario involves the btrfs/166 test case, which demonstrates the conditions under which the race condition manifests when the system runs out of space during relocation operations. This vulnerability affects systems where btrfs is used as the primary file system and where concurrent operations on block groups are common.
From an attack perspective, this vulnerability can be exploited by an attacker who can trigger the specific conditions that lead to the race condition, potentially causing denial of service or system crashes. The ATT&CK framework categorizes this as a system crash or hang technique, where an attacker can cause a kernel-level panic through manipulation of shared resources. The fix addresses the root cause by ensuring proper locking mechanisms are in place, which aligns with security best practices for concurrent programming and memory safety in kernel space. The solution demonstrates the importance of proper synchronization primitives in kernel-level code to prevent data corruption and maintain system stability. The vulnerability highlights the critical need for rigorous testing of concurrent code paths in kernel subsystems, particularly those dealing with memory management and resource allocation.