CVE-2026-80562: gpio: ml-ioh: use raw_spinlock_t for the register lock
In the Linux kernel, the following vulnerability has been resolved:
gpio: ml-ioh: use rawspinlockt for the register lock
iohirqtype() is registered as the irqchip .irqsettype callback and takes chip->spinlock with spinlockirqsave(). This callback is reached from setupirq() -> irqsettrigger() -> chip->irqsettype() while the caller holds desc->lock, a rawspinlockt, with hardirqs disabled. That context is not sleepable, but on PREEMPTRT a regular spinlockt is an rtmutex-backed sleeping lock, so acquiring it there is invalid. iohirqenable() and iohirqdisable() take the same lock from the .irqenable/.irqdisable callbacks, which are likewise invoked with desc->lock held.
Convert the register lock to rawspinlockt. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, and those critical sections only perform short sequences of MMIO register accesses (ioread32()/iowrite32()); the .irqsettype callback additionally emits a devwarn() on an unsupported type. None of these are sleepable operations, so keeping this register lock non-sleeping is appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.
This is the same fix as commit a02b8950d619 ("gpio: pch: use rawspinlockt for the register lock"); this driver shares the same structure as gpio-pch.
Affected Software
Event History
Frequently Asked Questions
Which systems are realistically affected by this issue?
The problematic locking behavior occurs on Linux kernels configured with PREEMPT_RT, where a regular spinlock_t can be backed by a sleeping rtmutex. Systems not using PREEMPT_RT do not have the described sleeping-lock conflict.
When can the invalid lock acquisition occur?
It can occur while configuring an interrupt trigger type through the ml-ioh driver's irq_set_type callback, and also through its irq_enable and irq_disable callbacks. These callbacks run while the IRQ descriptor raw lock is held and hard interrupts are disabled.
What is the mitigation if an updated kernel cannot be deployed immediately?
The provided information identifies PREEMPT_RT as the condition that makes the regular spinlock_t invalid in this context. Avoiding use of a PREEMPT_RT kernel prevents the described rtmutex-backed sleeping-lock behavior.