// For flags

CVE-2024-27005

interconnect: Don't access req_list while it's being manipulated

Severity Score

6.3
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: interconexión: no acceder a req_list mientras se está manipulando. El mutex icc_lock se dividió en mutex icc_lock e icc_bw_lock separados en [1] para evitar símbolos de bloqueo. Sin embargo, esto no protegió adecuadamente el acceso a icc_node::req_list. La función icc_set_bw() eventualmente iterará sobre req_list mientras solo mantiene icc_bw_lock, pero req_list se puede modificar mientras solo mantiene icc_lock. Esto provoca ejecucións entre icc_set_bw(), of_icc_get() e icc_put(). Ejemplo A: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&amp;icc_bw_lock); icc_put(ruta_b) mutex_lock(&amp;icc_lock); agregado_requests() hlist_for_each_entry(r, ... hlist_del(... Ejemplo B: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&amp;icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index( ) mutex_lock(&amp;icc_lock); path_find() path_init() agregado_requests() hlist_for_each_entry(r, ... hlist_add_head(... Solucione este problema asegurándose de que icc_bw_lock siempre se mantenga antes de manipular icc_node::req_list. El adicional Los lugares donde se mantiene icc_bw_lock no realizan ninguna asignación de memoria, por lo que aún deberíamos estar a salvo de los símbolos de bloqueo originales que motivaron los bloqueos separados [1] commit af42269c3523 ("interconexión: arreglar el bloqueo para runpm vs reclaim")

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
High
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-02-19 CVE Reserved
  • 2024-05-01 CVE Published
  • 2024-05-13 EPSS Updated
  • 2024-12-19 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.6.29
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.6.29"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.8.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.8.8"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.6 < 6.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.6 < 6.9"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
5.15.133
Search vendor "Linux" for product "Linux Kernel" and version "5.15.133"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
5.15.151
Search vendor "Linux" for product "Linux Kernel" and version "5.15.151"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
6.1.55
Search vendor "Linux" for product "Linux Kernel" and version "6.1.55"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
6.1.81
Search vendor "Linux" for product "Linux Kernel" and version "6.1.81"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
6.5.5
Search vendor "Linux" for product "Linux Kernel" and version "6.5.5"
en
Affected