mirror of
https://github.com/0xMarcio/cve.git
synced 2025-11-28 18:48:49 +00:00
18 lines
2.3 KiB
Markdown
18 lines
2.3 KiB
Markdown
### [CVE-2024-27005](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-27005)
|
|
|
|
|
|
|
|
|
|
### Description
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:interconnect: Don't access req_list while it's being manipulatedThe icc_lock mutex was split into separate icc_lock and icc_bw_lockmutexes in [1] to avoid lockdep splats. However, this didn't adequatelyprotect access to icc_node::req_list.The icc_set_bw() function will eventually iterate over req_list whileonly holding icc_bw_lock, but req_list can be modified while onlyholding 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 manipulatingicc_node::req_list. The additional places icc_bw_lock is held don'tperform any memory allocations, so we should still be safe from theoriginal lockdep splats that motivated the separate locks.[1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")
|
|
|
|
### POC
|
|
|
|
#### Reference
|
|
No PoCs from references.
|
|
|
|
#### Github
|
|
- https://github.com/fkie-cad/nvd-json-data-feeds
|
|
|