CVE-2024-35974 in Linux
Summary
by MITRE • 05/20/2024
In the Linux kernel, the following vulnerability has been resolved:
block: fix q->blkg_list corruption during disk rebind
Multiple gendisk instances can allocated/added for single request queue in case of disk rebind. blkg may still stay in q->blkg_list when calling blkcg_init_disk() for rebind, then q->blkg_list becomes corrupted.
Fix the list corruption issue by:
- add blkg_init_queue() to initialize q->blkg_list & q->blkcg_mutex only - move calling blkg_init_queue() into blk_alloc_queue()
The list corruption should be started since commit f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") which delays removing blkg from q->blkg_list into blkg_free_workfn().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2025
The vulnerability described in CVE-2024-35974 represents a critical issue within the Linux kernel's block layer subsystem that affects the proper management of block group (blkg) lists during disk rebind operations. This flaw specifically targets the interaction between the block cgroup subsystem and the request queue management mechanisms, creating a scenario where data structures become corrupted under specific conditions. The issue manifests when multiple gendisk instances are allocated and added to a single request queue during disk rebind operations, which creates a race condition or improper state management scenario.
The technical root cause of this vulnerability stems from improper initialization and management of the q->blkg_list data structure within the block layer. During disk rebind operations, when blkcg_init_disk() is called, there exists a possibility that block group references may still remain in the q->blkg_list even though they should have been removed. This occurs because the removal of blkg entries from the list has been delayed to occur within the blkg_free_workfn() function, as introduced in commit f1c006f1c685. This delay creates a window where the list contains stale references that conflict with new initialization processes, leading to corruption of the linked list structure that maintains block group associations with request queues.
The operational impact of this vulnerability extends beyond simple data corruption, potentially affecting system stability and performance in environments where disk rebind operations occur frequently. When the q->blkg_list becomes corrupted, it can lead to memory access violations, system crashes, or unpredictable behavior in storage I/O operations. The vulnerability affects systems that utilize block cgroup functionality for resource management and can be particularly problematic in virtualized environments or containerized deployments where disk rebind operations are common. The timing of the corruption makes it difficult to predict and reproduce, as it depends on the specific sequence of operations during disk rebind scenarios and the interaction between different kernel subsystems.
The fix implemented for this vulnerability addresses the core issue by introducing proper initialization ordering through the addition of blkg_init_queue() function that ensures q->blkg_list and q->blkcg_mutex are properly initialized only when needed. The solution moves the blkg_init_queue() call into the blk_alloc_queue() function, which establishes a clear initialization sequence that prevents the corruption from occurring during disk rebind operations. This approach aligns with established security practices for managing concurrent data structures and follows the principle of proper initialization ordering that prevents race conditions in kernel subsystems. The fix specifically addresses the CWE-121 heap-based buffer overflow and CWE-125 out-of-bounds read categories that commonly occur when list structures become corrupted. From an ATT&CK perspective, this vulnerability could be leveraged for privilege escalation or denial of service attacks, particularly in containerized environments where resource management is critical. The mitigation strategy ensures that the kernel's block layer maintains data integrity during dynamic resource reconfiguration operations, preventing potential exploitation that could compromise system stability or security boundaries.