In the Linux kernel, the following vulnerability has been resolved:
gpio: sch: use rawspinlockt in the irq startup path
schirqunmask() enables the GPIO IRQ and then updates the controller state through schirqmaskunmask(), which takes sch->lock with spinlockirqsave(). The callback can be reached from irqstartup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPTRT a regular spinlockt becomes a sleeping lock.
This issue was found by our static analysis tool and then manually reviewed against the current tree.
The grounded PoC kept the requestthreadedirq() -> _setupirq() -> irqstartup() -> schirqunmask() -> schirqmaskunmask() carrier and used the original spinlockirqsave(&sch->lock) edge. Lockdep reported:
BUG: sleeping function called from invalid context hardirqs last disabled at ... __setupirq.constprop.0 ... [vulnmsv] sch_rtspinlockirqsave+0x1c/0x30 [vulnmsv] schirqmaskunmask.constprop.0+0x31/0x70 [vulnmsv] __setupirq.constprop.0+0xd/0x30 [vulnmsv]
Convert the SCH controller lock to rawspinlockt. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64428.json"
}