CVE-2026-80562 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
gpio: ml-ioh: use raw_spinlock_t for the register lock
ioh_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. ioh_irq_enable() and ioh_irq_disable() take the same lock from the .irq_enable/.irq_disable callbacks, which are likewise invoked with desc->lock held.
Convert the register lock to raw_spinlock_t. 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 .irq_set_type callback additionally emits a dev_warn() 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 raw_spinlock_t for the register lock"); this driver shares the same structure as gpio-pch.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability addressed in this update pertains to improper locking semantics within the Linux kernel's GPIO ML-IOH driver, specifically involving the misuse of spinlocks in contexts that require non-sleepable execution. The core technical flaw lies in the use of a standard spinlock_t for the register lock instead of a raw_spinlock_t. This issue manifests primarily when the ioh_irq_type function is invoked as part of the irq_chip .irq_set_type callback chain, which originates from __setup_irq() leading to __irq_set_trigger(). In this execution path, the caller already holds desc->lock, which is implemented as a raw_spinlock with hard interrupts disabled. This creates an interrupt context that strictly prohibits sleeping operations. However, on systems configured with PREEMPT_RT patches, standard spinlocks are transformed into rtmutex-backed sleeping locks to support real-time preemption capabilities. Consequently, attempting to acquire the regular spinlock in this non-sleepable context results in a violation of kernel locking rules, potentially leading to deadlocks or system instability because the code attempts to sleep while holding a lock that forbids such behavior.
The operational impact of this vulnerability is significant for systems relying on PREEMPT_RT configurations, which are common in real-time industrial control and high-precision timing applications where deterministic latency is critical. If an attacker or automated testing tool can trigger the irq_set_type callback under these specific conditions, they may cause a kernel panic due to invalid context sleeping violations. Furthermore, since ioh_irq_enable() and ioh_irq_disable() also utilize this same lock from callbacks invoked while desc->lock is held, the vulnerability extends beyond just type configuration changes to include interrupt enablement and disablement operations. This broadens the attack surface for potential denial-of-service scenarios where system availability can be compromised by triggering these specific IRQ management paths on affected kernel configurations.
From a technical mitigation perspective, the resolution involves converting the register lock from spinlock_t to raw_spinlock_t. This change is appropriate because all critical sections protected by this lock perform only short sequences of memory-mapped I/O operations via ioread32() and iowrite32(), along with occasional dev_warn emissions for unsupported types. None of these operations are sleepable, meaning they do not require the scheduling capabilities provided by rtmutex-backed locks. By using raw_spinlock_t, the driver ensures compatibility with PREEMPT_RT environments without introducing sleeping violations in interrupt contexts. This fix aligns with established best practices for handling hardware register access in atomic contexts and mirrors similar corrections applied to related drivers such as gpio-pch, ensuring consistency across the kernel's GPIO subsystem.
This issue is categorized under CWE-674, which covers Uncontrolled Recursion, although more accurately it falls under improper locking mechanisms that lead to deadlocks or race conditions in concurrent execution environments. In terms of MITRE ATT&CK mapping, this vulnerability relates to techniques involving exploitation of software vulnerabilities for denial-of-service, specifically leveraging incorrect synchronization primitives to disrupt system stability. The fix ensures that the driver adheres to strict atomic context constraints, preventing potential exploits that target locking inconsistencies in real-time kernel configurations. Maintaining proper lock types is essential for preserving system integrity and ensuring that hardware interaction routines remain robust against both accidental triggers and malicious exploitation attempts aimed at destabilizing critical infrastructure components.