CVE-2026-74468: gpio: pch: use raw_spinlock_t for the register lock
In the Linux kernel, the following vulnerability has been resolved:
gpio: pch: use rawspinlockt for the register lock
pchirqtype() 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.
This was confirmed on a PREEMPTRT kernel with lockdep (PROVERAWLOCKNESTING and DEBUGATOMICSLEEP). A grounded PoC mirrored pchirqtype()'s locking and drove it through the real genirq carrier irqsetirqtype() -> irqsettrigger() -> chip->irqsettype(), i.e. the same irqsettrigger() edge that setupirq() takes for a requested IRQ. With the original spinlockirqsave() edge lockdep reported an invalid wait context, immediately followed by:
BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 95, name: insmod hardirqs last disabled at (3784): rawspinlockirqsave+0x4f/0x60 rtspinlock+0x3a/0x1c0 reproirqsettype+0x64/0xa0 [pchrepro] irqsettrigger+0x69/0x140 irqsetirqtype+0x78/0xd0
Switching the mirrored lock to rawspinlockt made both splats go away.
Convert the register lock to rawspinlockt. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irqsethandlerlocked(); none of them 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.
This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 ("gpio: sch: use rawspinlockt in the irq startup path") and commit 90f0109019e6 ("gpio: eic-sprd: use rawspinlockt in the irq startup path").
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernel GPIO register lock (PREEMPT_RT)to a version that resolves this vulnerability.Patch 286533cb14a3 - Upgrade
Upgrade
Linux kernel GPIO register lock (PREEMPT_RT)to a version that resolves this vulnerability.Patch 90f0109019e6 - Configuration
Convert the GPIO register lock to raw_spinlock_t and use the raw_spin_lock_irqsave() style locking for the MMIO register accesses (ioread32()/iowrite32()) so the lock is non-sleeping on PREEMPT_RT.
Linux kernel GPIO register lock lock type = raw_spinlock_t (instead of spinlock_t/spin_lock_irqsave() edge lock)
Event History
Frequently Asked Questions
What is the severity of CVE-2026-74468?
The severity of CVE-2026-74468 is rated at 12.
How do I fix CVE-2026-74468?
To fix CVE-2026-74468, ensure that the Linux kernel is updated to the latest patched version.
What components are affected by CVE-2026-74468?
CVE-2026-74468 affects the GPIO subsystem in the Linux kernel.
What is the nature of the vulnerability in CVE-2026-74468?
CVE-2026-74468 involves improper locking mechanisms that could lead to race conditions.
When was CVE-2026-74468 published?
CVE-2026-74468 was published on August 15, 2026.