DEBIAN-CVE-2024-27005

In the Linux kernel, the following vulnerability has been resolved: interconnect: Don't access reqlist 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, ... hlistdel(... <r = invalid pointer> Example B: CPU0 CPU1 ---- ---- iccsetbw(patha) mutexlock(&iccbwlock); pathb = oficcget() oficcgetbyindex() mutexlock(&icclock); pathfind() pathinit() aggregaterequests() hlistforeachentry(r, ... hlistaddhead(... <r = invalid pointer> Fix this by ensuring iccbwlock is always held before manipulating iccnode::reqlist. The additional places iccbw_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")