CVE-2024-27005 in Linux
Summary
by MITRE • 05/01/2024
In the Linux kernel, the following vulnerability has been resolved:
interconnect: Don't access req_list while it's being manipulated
The icc_lock mutex was split into separate icc_lock and icc_bw_lock mutexes in [1] to avoid lockdep splats. However, this didn't adequately
protect access to icc_node::req_list.
The icc_set_bw() function will eventually iterate over req_list while only holding icc_bw_lock, but req_list can be modified while only holding icc_lock. This causes races between icc_set_bw(), of_icc_get(), and icc_put().
Example A:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... <r = invalid pointer>
Example B:
CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... <r = invalid pointer>
Fix this by ensuring icc_bw_lock is always held before manipulating icc_node::req_list. The additional places icc_bw_lock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks.
[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/07/2026
The vulnerability described in CVE-2024-27005 resides within the Linux kernel's interconnect subsystem, specifically concerning improper locking mechanisms that lead to race conditions during concurrent access to shared data structures. This issue manifests in the icc_node::req_list data structure which manages requests for interconnect bandwidth allocation. The root cause stems from an incomplete refactoring of locking mechanisms that was intended to resolve lockdep splats but inadvertently introduced new concurrency problems. The original change split the icc_lock mutex into two separate mutexes - icc_lock and icc_bw_lock - to address conflicting lock ordering dependencies. However, this refactoring failed to properly protect access to the req_list data structure, creating a scenario where different functions could manipulate the list while only holding one of the two locks.
The technical flaw occurs in the icc_set_bw() function which iterates over the req_list while holding only the icc_bw_lock mutex. Meanwhile, functions like of_icc_get() and icc_put() can modify the req_list while holding only the icc_lock mutex, creating a classic race condition scenario. The vulnerability is particularly concerning because it can result in invalid pointer dereferences when the hlist_for_each_entry() macro attempts to traverse a req_list that has been modified concurrently. This type of race condition falls under CWE-362, which specifically addresses concurrent execution using shared data structures without proper synchronization mechanisms. The improper locking pattern allows for situations where a request node that was valid when the iteration began could be removed by another thread, leading to use-after-free conditions or null pointer dereferences.
The operational impact of this vulnerability is significant as it can lead to system instability, kernel panics, or potential privilege escalation scenarios. When concurrent threads access the interconnect subsystem simultaneously, the race conditions can cause unpredictable behavior in memory management and resource allocation. The vulnerability affects any system utilizing the Linux kernel's interconnect framework, particularly those with complex power management scenarios where runtime power management (runpm) interacts with memory reclaim operations. Systems running on platforms that heavily utilize interconnect bandwidth management for CPU, GPU, or memory controllers are particularly at risk. The attack surface is broad as any application or kernel subsystem that interacts with the interconnect framework could potentially trigger this race condition. According to ATT&CK framework, this vulnerability could be leveraged for privilege escalation through kernel memory corruption or for denial of service by causing system crashes.
The fix implemented addresses this issue by ensuring that icc_bw_lock is always held before manipulating the icc_node::req_list data structure. This approach maintains the original intent of separating the locks to avoid lockdep splats while properly protecting the shared data structure. The solution requires that all functions modifying req_list must acquire icc_bw_lock before making any changes, which eliminates the race condition between icc_set_bw(), of_icc_get(), and icc_put() functions. This fix maintains the performance benefits of the original lock separation while ensuring memory safety through proper synchronization. The additional places where icc_bw_lock is held do not perform memory allocations, which prevents the reintroduction of the original lockdep issues that motivated the initial refactoring. The solution aligns with best practices for concurrent programming in kernel space, where shared data structures must be protected by appropriate synchronization primitives that guarantee atomic access to critical sections. This fix ensures that the interconnect subsystem maintains its integrity under concurrent access patterns while preserving the intended lock ordering optimizations.