CVE-2026-74468: gpio: pch: use raw_spinlock_t for the register lock

Published Aug 15, 2026
·
Updated

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.

  1. Upgrade

    Upgrade Linux kernel GPIO register lock (PREEMPT_RT) to a version that resolves this vulnerability.

    Patch 286533cb14a3
  2. Upgrade

    Upgrade Linux kernel GPIO register lock (PREEMPT_RT) to a version that resolves this vulnerability.

    Patch 90f0109019e6
  3. 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

Aug 15, 2026
CVE Published
via MITRE·12:27 PM
Data Sourced
via MITRE·12:27 PM
Description
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-74468?

The severity of CVE-2026-74468 is rated at 12.

2

How do I fix CVE-2026-74468?

To fix CVE-2026-74468, ensure that the Linux kernel is updated to the latest patched version.

3

What components are affected by CVE-2026-74468?

CVE-2026-74468 affects the GPIO subsystem in the Linux kernel.

4

What is the nature of the vulnerability in CVE-2026-74468?

CVE-2026-74468 involves improper locking mechanisms that could lead to race conditions.

5

When was CVE-2026-74468 published?

CVE-2026-74468 was published on August 15, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203