Linux Kernel
CVE-2024-27005
HIGH
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Race conditions require precise concurrent thread timing, warranting AC:H over NVD's AC:L; PR:L and AV:L are correct; all three impacts are High due to potential kernel memory corruption.
Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).
CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Lifecycle Timeline
7DescriptionCVE.org
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")
AnalysisAI
Race condition in the Linux kernel's interconnect (ICC) subsystem exposes systems to concurrent req_list corruption, with a CVSS 7.8 High rating and potential for high-impact memory corruption by local low-privileged users. The vulnerability stems from an incomplete mutex refactor: icc_set_bw() iterates over icc_node::req_list while holding only icc_bw_lock, while icc_put() and of_icc_get() can concurrently modify req_list under only icc_lock, producing dangling or invalid pointer dereferences. No public exploit code exists and EPSS sits at 0.18% (7th percentile), indicating negligible observed exploitation pressure despite the theoretical severity.
Technical ContextAI
The affected subsystem is the Linux kernel's on-chip interconnect (ICC) framework, which abstracts bandwidth and latency management for system-on-chip (SoC) bus interconnects - hardware typical in ARM-based mobile, embedded, and edge devices. CPE data confirms affected products span multiple Linux kernel stable branches plus pre-release versions 6.9-rc1 through 6.9-rc4 (cpe:2.3:o:linux:linux_kernel). CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization) precisely describes the root cause: commit af42269c3523 split the original icc_lock mutex into icc_lock and icc_bw_lock to resolve lockdep warnings, but left a synchronization gap. icc_set_bw() acquires only icc_bw_lock when iterating hlist_for_each_entry over req_list, while of_icc_get() and icc_put() acquire only icc_lock when calling hlist_add_head or hlist_del on that same list - creating a classic TOCTOU window where one CPU holds a pointer to a list node that another CPU is simultaneously freeing or reinserting.
RemediationAI
Apply the upstream kernel patches available at https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6, https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42, and https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1 - these commits ensure icc_bw_lock is held before any manipulation of icc_node::req_list, closing the synchronization gap. The exact patched stable-kernel release version is not independently confirmed from available data; the patch is available per vendor (upstream kernel stable tree) and Fedora advisory. Fedora users should apply the distribution kernel update referenced in the package-announce advisories. On systems where kernel patching is not immediately feasible, restricting which unprivileged processes can invoke ICC-related driver interfaces (via seccomp filtering or restricting driver access through device node permissions) reduces exposure, though this trade-off may impact driver functionality on SoC platforms that rely on dynamic bandwidth management.
Same weakness CWE-362 – Race Condition
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today