CVE-2024-27005

Advisory lineage Upstream: 0 Downstream: 15
Modified
Published: 01 May 2024, 05:28
Last modified:23 May 2026, 15:41

Vulnerability Summary

Overall Risk (default)
medium
25/100
CVSS Score
6.3 MEDIUM
v3.1 (cve.org)
EPSS Score
<0.01% LOW
0% probability 0.00%
KEV
Not listed
Ransomware
No reports
Public exploits
None found
Dark Web
Not detected

Timeline

01 May 2024, 05:28
Published
Vulnerability first disclosed
23 May 2026, 15:41
Last Modified
Vulnerability information updated

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

CVSS Metrics

  • v3.1•MEDIUM•Score: 6.3CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H

EPSS Trends

Current EPSS score: 0.01%• Percentile: 1%

Techniques & Countermeasures

  • CWE-362•Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

    The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

  • CWE-667•Improper Locking

    The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Affected Systems

  • linux•linux

    ≥ 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 | 6.6

  • linux•linux_kernel

    ≥ 5.15.133, < 5.16 | ≥ 6.1.55, < 6.2 | ≥ 6.5.5, < 6.6.29 | ≥ 6.7, < 6.8.8 | 6.9:rc1 | 6.9:rc2 | 6.9:rc3 | 6.9:rc4

References (8)