PT-2026-64649 · Linux · Linux
CVE-2026-64428
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
gpio: sch: use raw spinlock t in the irq startup path
sch irq unmask() enables the GPIO IRQ and then updates the controller
state through sch irq mask unmask(), which takes sch->lock with
spin lock irqsave(). The callback can be reached from irq startup()
while setting up a requested IRQ. That path is not sleepable, but on
PREEMPT RT a regular spinlock t 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 request threaded irq() -> setup irq() ->
irq startup() -> sch irq unmask() -> sch irq mask unmask() carrier and
used the original spin lock irqsave(&sch->lock) edge. Lockdep reported:
BUG: sleeping function called from invalid context
hardirqs last disabled at ... setup irq.constprop.0 ... [vuln msv]
sch rt spin lock irqsave+0x1c/0x30 [vuln msv]
sch irq mask unmask.constprop.0+0x31/0x70 [vuln msv]
setup irq.constprop.0+0xd/0x30 [vuln msv]
Convert the SCH controller lock to raw spinlock t. 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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux