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 spinlockt, 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 rawspinlockirqsave counterpushevent [counter] interruptcntisr [interruptcnt] _handleirqeventpercpu 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.