In the Linux kernel, the following vulnerability has been resolved: firmware: armsdei: Fix sleep from invalid context BUG Running a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altra triggers: BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:46 inatomic(): 0, irqsdisabled(): 128, nonblock: 0, pid: 24, name: cpuhp/0 preemptcount: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpuhotpluglock){++++}-{0:0}, at: cpuhpthreadfun+0x5c/0x248 #1: ffffda30217c7120 (cpuhpstate-up){+.+.}-{0:0}, at: cpuhpthreadfun+0x5c/0x248 #2: ffffda3021c711f0 (sdeilistlock){....}-{3:3}, at: sdeicpuhpup+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [<ffffda301e85b7bc>] finishtaskswitch+0xb4/0x2b0 hardirqs last disabled at (36): [<ffffda301e812fec>] cpuhpthreadfun+0x21c/0x248 softirqs last enabled at (0): [<ffffda301e80b184>] copyprocess+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dumpbacktrace+0x114/0x120 showstack+0x20/0x70 dumpstacklvl+0x9c/0xd8 dumpstack+0x18/0x34 _mightresched+0x188/0x228 rtspinlock+0x70/0x120 sdeicpuhpup+0x3c/0x130 cpuhpinvokecallback+0x250/0xf08 cpuhpthreadfun+0x120/0x248 smpbootthreadfn+0x280/0x320 kthread+0x130/0x140 retfromfork+0x10/0x20 sdeicpuhpup() is called in the STARTING hotplug section, which runs with interrupts disabled. Use a CPUHPAPONLINEDYN entry instead to execute the cpuhp cb later, with preemption enabled. SDEI originally got its own cpuhp slot to allow interacting with perf. It got superseded by pNMI and this early slot is not relevant anymore. [1] Some SDEI calls (e.g. SDEI10FNSDEIPEMASK) take actions on the calling CPU. It is checked that preemption is disabled for them. ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'. Preemption is enabled in those threads, but their cpumask is limited to 1 CPU. Move 'WARNONONCE(preemptible())' statements so that SDEI cpuhp cb don't trigger them. Also add a check for the SDEI10FNSDEIPRIVATE_RESET SDEI call which acts on the calling CPU. [1]: https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/