CVE-2024-27005: interconnect: Don't access req_list while it's being manipulated

Severity: high (CVSS 7.8 v3.1)
Exploited in the wild: not listed in CISA KEV
EPSS: 0.2% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2024-05-01 · updated 2026-10-30
Weakness: CWE-362

Description

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")

Affected products

Linux kernel: from 5.15.133 before 5.16; from 6.1.55 before 6.2; from 6.5.5 before 6.6.29; from 6.7 before 6.8.8; 6.9-rc1, 6.9-rc2, 6.9-rc3, 6.9-rc4 — fixed in 5.16, 6.2, 6.6.29, 6.8.8
Linux: from 5.15.133 before 5.15.151; from 6.1.55 before 6.1.81; from 6.5.5 before 6.6 — fixed in 5.15.151, 6.1.81, 6.6

How to fix

Upgrade to a fixed version: Linux kernel 5.16, 6.2, 6.6.29, 6.8.8; Linux 5.15.151, 6.1.81, 6.6. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2024-27005 or the next vulnerability affects your stack