CVE-2024-27005

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: Don&amp;#39;t access req_list while it&amp;#39;s being manipulated<br /> <br /> The icc_lock mutex was split into separate icc_lock and icc_bw_lock<br /> mutexes in [1] to avoid lockdep splats. However, this didn&amp;#39;t adequately<br /> protect access to icc_node::req_list.<br /> <br /> The icc_set_bw() function will eventually iterate over req_list while<br /> only holding icc_bw_lock, but req_list can be modified while only<br /> holding icc_lock. This causes races between icc_set_bw(), of_icc_get(),<br /> and icc_put().<br /> <br /> Example A:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> icc_set_bw(path_a)<br /> mutex_lock(&amp;icc_bw_lock);<br /> icc_put(path_b)<br /> mutex_lock(&amp;icc_lock);<br /> aggregate_requests()<br /> hlist_for_each_entry(r, ...<br /> hlist_del(...<br /> <br /> <br /> Example B:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> icc_set_bw(path_a)<br /> mutex_lock(&amp;icc_bw_lock);<br /> path_b = of_icc_get()<br /> of_icc_get_by_index()<br /> mutex_lock(&amp;icc_lock);<br /> path_find()<br /> path_init()<br /> aggregate_requests()<br /> hlist_for_each_entry(r, ...<br /> hlist_add_head(...<br /> <br /> <br /> Fix this by ensuring icc_bw_lock is always held before manipulating<br /> icc_node::req_list. The additional places icc_bw_lock is held don&amp;#39;t<br /> perform any memory allocations, so we should still be safe from the<br /> original lockdep splats that motivated the separate locks.<br /> <br /> [1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")