CVE-2026-80562: Linux Kernel GPIO Race Condition Vulnerability

CVE-2026-80562 Overview

CVE-2026-80562 affects the Linux kernel gpio-ml-ioh driver. The driver uses a regular spinlock_t for its register lock. On PREEMPT_RT kernels, spinlock_t becomes an rtmutex-backed sleeping lock. The irq_chip callbacks ioh_irq_type(), ioh_irq_enable(), and ioh_irq_disable() acquire that lock from a non-sleepable context, because the caller already holds desc->lock (a raw_spinlock_t) with hardirqs disabled. Acquiring a sleeping lock in that context is invalid and produces sleeping-while-atomic behavior on real-time kernels. The fix converts the register lock to raw_spinlock_t, mirroring commit a02b8950d619 for the sibling gpio-pch driver.

Critical Impact
On PREEMPT_RT kernels, invoking GPIO IRQ callbacks on ML-IOH hardware can trigger a sleeping-in-atomic-context fault, leading to kernel warnings, lock corruption, or a system crash.

Affected Products

Linux kernel gpio-ml-ioh driver (Intel EG20T ML-IOH GPIO controller)
Kernels built with CONFIG_PREEMPT_RT prior to the fix
Stable kernel branches referenced by the eight backport commits listed by kernel.org

Discovery Timeline

2026-08-26 - CVE-2026-80562 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-80562

Vulnerability Analysis

The gpio-ml-ioh driver registers ioh_irq_type() as the .irq_set_type callback of its irq_chip. The generic IRQ core reaches this callback through __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while holding desc->lock, which is a raw_spinlock_t, with hardirqs disabled. That execution context is atomic and non-sleepable.

Inside the callback, the driver takes chip->spinlock with spin_lock_irqsave(). On kernels without PREEMPT_RT, spinlock_t is a true spinning primitive and the sequence is safe. On PREEMPT_RT, spinlock_t is redefined as an rtmutex-backed sleeping lock. Attempting to acquire it from atomic context violates the locking contract and triggers the scheduler's atomic-context checks.

The same defect applies to ioh_irq_enable() and ioh_irq_disable(), which are invoked from .irq_enable and .irq_disable while desc->lock is held. The register lock also serializes GPIO direction and value callbacks plus suspend/resume save-and-restore paths, all of which perform only short ioread32() and iowrite32() MMIO sequences.

Root Cause

The driver used the wrong lock type for a lock reached from a hard-IRQ-disabled, raw_spinlock_t-protected context on real-time kernels. Because none of the critical sections perform sleepable work, the correct primitive is raw_spinlock_t.

Attack Vector

This is a kernel locking correctness defect, not a remotely reachable memory-safety flaw. Impact is limited to systems that ship the ML-IOH GPIO controller and run a PREEMPT_RT kernel. Triggering the invalid context requires the normal IRQ setup path on that hardware. There is no evidence of remote exploitation, and no CVSS vector, CWE, or public PoC has been published for this identifier.

See the kernel.org fix commit 431b101 and the analogous gpio-pch fix commit a02b8950d619 reference for the exact source changes.

Detection Methods for CVE-2026-80562

Indicators of Compromise

Kernel log entries containing BUG: sleeping function called from invalid context referencing gpio-ml-ioh or ioh_irq_type on PREEMPT_RT builds.
might_sleep splats or lockdep warnings emitted during IRQ setup for ML-IOH GPIO lines.
Unexpected kernel panics or hangs during boot or device probe on real-time systems using EG20T ML-IOH hardware.

Detection Strategies

Inventory kernel versions and identify hosts running PREEMPT_RT with the gpio-ml-ioh module loaded (lsmod | grep ml_ioh).
Compare running kernel commit hashes against the eight stable backports listed on kernel.org for CVE-2026-80562.
Enable CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING in test builds to surface the invalid acquisition during QA.

Monitoring Recommendations

Forward dmesg and journald kernel facility logs to a central log store and alert on sleeping function called from invalid context patterns.
Track kernel crash artifacts (kdump, pstore) originating from GPIO or IRQ subsystems on affected hardware.
Watch package management events for kernel upgrades on real-time hosts to confirm the fix commit is deployed.

How to Mitigate CVE-2026-80562

Immediate Actions Required

Apply the stable kernel update that includes the gpio: ml-ioh: use raw_spinlock_t for the register lock change on all affected hosts.
Prioritize systems running PREEMPT_RT with ML-IOH GPIO hardware, since they are the only configurations where the defect is reachable.
Reboot into the patched kernel and verify the fix commit is present with git log or distribution changelogs.

Patch Information

The fix converts chip->spinlock from spinlock_t to raw_spinlock_t and updates all spin_lock_irqsave/spin_unlock_irqrestore sites to the raw_spin_* variants. Backports are available in the following kernel.org commits: 0559b86, 359e6b1, 431b101, 600411e, 63d2230, 84be002, b6505a4, and bc7934d.

Workarounds

Run a non-PREEMPT_RT kernel on hosts with ML-IOH GPIO controllers until the patched kernel is deployed.
Blacklist the gpio_ml_ioh module on real-time systems that do not require the controller by adding blacklist gpio_ml_ioh to /etc/modprobe.d/.
Restrict physical and administrative access on affected hosts to reduce the chance of triggering IRQ setup during evaluation.

bash

# Verify kernel version and confirm ml-ioh module state
uname -r
lsmod | grep ml_ioh

# Optional workaround: disable the module on PREEMPT_RT hosts pending patch
echo 'blacklist gpio_ml_ioh' | sudo tee /etc/modprobe.d/blacklist-gpio-ml-ioh.conf
sudo update-initramfs -u