AZL-93617

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.