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 icclock mutex was split into separate icclock and iccbwlock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to iccnode::reqlist.

The iccsetbw() function will eventually iterate over reqlist while only holding iccbwlock, but reqlist can be modified while only holding icclock. This causes races between iccsetbw(), oficcget(), and iccput().

Example A:

CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); iccput(pathb) mutexlock(&icclock); aggregaterequests() hlistforeachentry(r, ... hlist_del(... <r = invalid pointer>

Example B:

CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); pathb = oficcget() oficcgetbyindex() mutexlock(&icclock); pathfind() pathinit() aggregaterequests() hlistforeachentry(r, ... hlistadd_head(... <r = invalid pointer>

Fix this by ensuring iccbwlock is always held before manipulating iccnode::reqlist. The additional places iccbwlock 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")