cbcvebase.
CVE-2024-27005
published 2024-05-01

CVE-2024-27005: 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…

PriorityP428medium6.3CVSS 3.1
AVLACHPRLUINSUCHINAH
EPSS
0.18%
7.4th percentile
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(... 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(... 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

29 ranges· showing 25
VendorProductVersion rangeFixed in
debianlinux< linux 6.8.9-1 (forky)linux 6.8.9-1 (forky)
linuxlinux
linuxlinux
linuxlinux>= 5.15.133 < 5.15.1515.15.151
linuxlinux>= 6.1.55 < 6.1.816.1.81
linuxlinux>= 6.5.5 < 6.66.6
linuxlinux>= 9be2957f014d91088db1eb5dd09d9a03d7184dce < fe549d8e976300d0dd75bd904eb216bed8b145e0fe549d8e976300d0dd75bd904eb216bed8b145e0
linuxlinux>= af42269c3523492d71ebbe11fefae2653e9cdc78 < d0d04efa2e367921654b5106cc5c05e3757c2b42d0d04efa2e367921654b5106cc5c05e3757c2b42
linuxlinux>= af42269c3523492d71ebbe11fefae2653e9cdc78 < 4c65507121ea8e0b47fae6d2049c8688390d46b64c65507121ea8e0b47fae6d2049c8688390d46b6
linuxlinux>= af42269c3523492d71ebbe11fefae2653e9cdc78 < de1bf25b6d771abdb52d43546cf57ad775fb68a1de1bf25b6d771abdb52d43546cf57ad775fb68a1
linuxlinux>= ee42bfc791aa3cd78e29046f26a09d189beb3efb < 19ec82b3cad1abef2a929262b8c1528f4e0c192d19ec82b3cad1abef2a929262b8c1528f4e0c192d
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel
linuxlinux_kernel>= 0 < 6.8.9-16.8.9-1
linuxlinux_kernel>= 0 < 6.8.9-16.8.9-1
linuxlinux_kernel>= 0 < 6.8.0-38.386.8.0-38.38
linuxlinux_kernel>= 5.15.133 < 5.165.16
linuxlinux_kernel>= 6.1.55 < 6.26.2
linuxlinux_kernel>= 6.5.5 < 6.6.296.6.29
linuxlinux_kernel>= 6.7 < 6.8.86.8.8
msrcazl3_hyperv-daemons_6.6.22.1-2_on_azure_linux_3.0
msrcazl3_hyperv-daemons_6.6.35.1-1_on_azure_linux_3.0
msrcazure_linux_3.0_arm

CVSS provenance

nvdv3.16.3MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
osv6.8MEDIUM
vendor_debian6.3LOW
vendor_msrc6.3MEDIUM
vendor_redhat6.3MEDIUM
vendor_ubuntu4.6MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.