DEBIAN-CVE-2024-36888

In the Linux kernel, the following vulnerability has been resolved: workqueue: Fix selection of wakecpu in kickpool() With cpupossiblemask=0-63 and cpuonlinemask=0-7 the following kernel oops was observed: smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 8 CPUs Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000803 [..] Call Trace: archvcpuispreempted+0x12/0x80 selectidlesibling+0x42/0x560 selecttaskrqfair+0x29a/0x3b0 trytowakeup+0x38e/0x6e0 kickpool+0xa4/0x198 _queuework.part.0+0x2bc/0x3a8 calltimerfn+0x36/0x160 _runtimers+0x1e2/0x328 _runtimerbase+0x5a/0x88 runtimersoftirq+0x40/0x78 _dosoftirq+0x118/0x388 irqexitrcu+0xc0/0xd8 doextirq+0xae/0x168 extinthandler+0xbe/0xf0 pswidleexit+0x0/0xc defaultidlecall+0x3c/0x110 doidle+0xd4/0x158 cpustartupentry+0x40/0x48 restinit+0xc6/0xc8 startkernel+0x3c4/0x5e0 startupcontinue+0x3c/0x50 The crash is caused by calling archvcpuispreempted() for an offline CPU. To avoid this, select the cpu with cpumaskanyanddistribute() to mask _podcpumask with cpuonlinemask. In case no cpu is left in the pool, skip the assignment. tj: This doesn't fully fix the bug as CPUs can still go down between picking the target CPU and the wake call. Fixing that likely requires adding cpuonline() test to either the sched or s390 arch code. However, regardless of how that is fixed, workqueue shouldn't be picking a CPU which isn't online as that would result in unpredictable and worse behavior.