CVE-2026-80562

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: ml-ioh: use raw_spinlock_t for the register lock<br /> <br /> ioh_irq_type() is registered as the irq_chip .irq_set_type callback and<br /> takes chip-&gt;spinlock with spin_lock_irqsave(). This callback is reached<br /> from __setup_irq() -&gt; __irq_set_trigger() -&gt; chip-&gt;irq_set_type() while<br /> the caller holds desc-&gt;lock, a raw_spinlock_t, with hardirqs disabled.<br /> That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is<br /> an rtmutex-backed sleeping lock, so acquiring it there is invalid.<br /> ioh_irq_enable() and ioh_irq_disable() take the same lock from the<br /> .irq_enable/.irq_disable callbacks, which are likewise invoked with<br /> desc-&gt;lock held.<br /> <br /> Convert the register lock to raw_spinlock_t. The same lock also<br /> serializes the GPIO direction/value callbacks and the suspend/resume<br /> register save/restore, and those critical sections only perform short<br /> sequences of MMIO register accesses (ioread32()/iowrite32()); the<br /> .irq_set_type callback additionally emits a dev_warn() on an unsupported<br /> type. None of these are sleepable operations, so keeping this register<br /> lock non-sleeping is appropriate for the irqchip callbacks and does not<br /> change the GPIO-side locking contract.<br /> <br /> This is the same fix as commit a02b8950d619 ("gpio: pch: use<br /> raw_spinlock_t for the register lock"); this driver shares the same<br /> structure as gpio-pch.