CVE-2024-27005High· 7.8▾ TwilightIn 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 sp…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 42.9 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the assigning CNA record, not NVD.
Exploit-prediction probability, daily snapshots since Nov 3.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
Last analysed / modified upstream
0.2%
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")
Linux >= 9be2957f014d91088db1eb5dd09d9a03d7184dce < fe549d8e976300d0dd75bd904eb216bed8b145e0Linux >= ee42bfc791aa3cd78e29046f26a09d189beb3efb < 19ec82b3cad1abef2a929262b8c1528f4e0c192dLinux >= ffb8917c70a4c88725ee40f9eeee9240ad1c1869 < 8401bc2c188030fb14d1cb43c402a1cf42d86dd2Linux >= af42269c3523492d71ebbe11fefae2653e9cdc78 < d0d04efa2e367921654b5106cc5c05e3757c2b42Linux >= af42269c3523492d71ebbe11fefae2653e9cdc78 < 4c65507121ea8e0b47fae6d2049c8688390d46b6Linux >= af42269c3523492d71ebbe11fefae2653e9cdc78 < de1bf25b6d771abdb52d43546cf57ad775fb68a1Linux 2f3a124696d43de3c837f87a9f767c56ee86cf2aLinux >= 5.15.133 < 5.15.151Linux >= 6.1.55 < 6.1.81Linux >= 6.5.5 < 6.6Linux 6.6Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99284Nonenet: skbuff: propagate shared-frag marker in skb_zerocopy()
CVE-2026-99283Nonenetfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
CVE-2026-99272Nonesmb: client: validate the data area in SMB2_read()
CVE-2026-99271NoneALSA: line6: Clear prev_fbuf on capture buffer release
CVE-2026-99273Noneksmbd: reserve space for the UTF-16 terminator in stream info
CVE-2026-99275Nonesmb: client: reject short SESSION_SETUP responses