In the Linux kernel, the following vulnerability has been resolved:

counter: interrupt-cnt: Drop IRQFNOTHREAD flag

An IRQ handler can either be IRQFNOTHREAD or acquire spinlock_t, as

CONFIGPROVERAWLOCKNESTING warns:

[ BUG: Invalid wait context ]

6.18.0-rc1+git... #1

some-user-space-process/1251 is trying to lock: (&counter->eventslistlock){....}-{3:3}, at: counterpushevent [counter] other info that might help us debug this: context-{2:2} no locks held by some-user-space-process/.... stack backtrace: CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT Call trace: showstack (C) dumpstacklvl dumpstack __lockacquire lockacquire rawspin_lockirqsave counterpushevent [counter] interruptcntisr [interruptcnt] __handleirqevent_percpu handleirqevent handlesimpleirq handleirqdesc generichandledomainirq gpioirqhandler handleirqdesc generichandledomainirq gichandleirq callonirqstack dointerrupthandler el0interrupt __el0irqhandlercommon el0t64irqhandler el0t64irq

... and Sebastian correctly points out. Remove IRQFNOTHREAD as an alternative to switching to rawspinlockt, because the latter would limit all potential nested locks to rawspinlockt only.