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
[ BUG: Invalid wait context ]
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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/71xxx/CVE-2025-71180.json"
}