Answer in brief
CVE-2024-27005 records a Unknown severity vulnerability in interconnect: Don't access req_list while it's being manipulated. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2024-27005 records a Unknown severity vulnerability in interconnect: Don't access req_list while it's being manipulated. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9be2957f014d91088db1eb5dd09d9a03d7184dce <fe549d8e976300d0dd75bd904eb216bed8b145e0 || >=ee42bfc791aa3cd78e29046f26a09d189beb3efb <19ec82b3cad1abef2a929262b8c1528f4e0c192d || >=af42269c3523492d71ebbe11fefae2653e9cdc78 <d0d04efa2e367921654b5106cc5c05e3757c2b42 || >=af42269c3523492d71ebbe11fefae2653e9cdc78 <4c65507121ea8e0b47fae6d2049c8688390d46b6 || >=af42269c3523492d71ebbe11fefae2653e9cdc78 <de1bf25b6d771abdb52d43546cf57ad775fb68a1 || 2f3a124696d43de3c837f87a9f767c56ee86cf2a || >=5.15.133 <5.15.151 || >=6.1.55 <6.1.81 || >=6.5.5 <6.6 | fe549d8e976300d0dd75bd904eb216bed8b145e0, 19ec82b3cad1abef2a929262b8c1528f4e0c192d, d0d04efa2e367921654b5106cc5c05e3757c2b42, 4c65507121ea8e0b47fae6d2049c8688390d46b6, de1bf25b6d771abdb52d43546cf57ad775fb68a1, 5.15.151, 6.1.81, 6.6 |
| Linux/Linuxgeneric | 6.6 | Not reported |
Published upstream
May 1, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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")
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9be2957f014d91088db1eb5dd09d9a03d7184dce <fe549d8e976300d0dd75bd904eb216bed8b145e0 || >=ee42bfc791aa3cd78e29046f26a09d189beb3efb <19ec82b3cad1abef2a929262b8c1528f4e0c192d || >=af42269c3523492d71ebbe11fefae2653e9cdc78 <d0d04efa2e367921654b5106cc5c05e3757c2b42 || >=af42269c3523492d71ebbe11fefae2653e9cdc78 <4c65507121ea8e0b47fae6d2049c8688390d46b6 || >=af42269c3523492d71ebbe11fefae2653e9cdc78 <de1bf25b6d771abdb52d43546cf57ad775fb68a1 || 2f3a124696d43de3c837f87a9f767c56ee86cf2a || >=5.15.133 <5.15.151 || >=6.1.55 <6.1.81 || >=6.5.5 <6.6 | fe549d8e976300d0dd75bd904eb216bed8b145e0, 19ec82b3cad1abef2a929262b8c1528f4e0c192d, d0d04efa2e367921654b5106cc5c05e3757c2b42, 4c65507121ea8e0b47fae6d2049c8688390d46b6, de1bf25b6d771abdb52d43546cf57ad775fb68a1, 5.15.151, 6.1.81, 6.6 |
| Linux/Linuxgeneric | 6.6 | Not reported |
Published upstream
May 1, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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")
Quoted source text, attributed separately from HOL analysis.