Description
In the Linux kernel, the following vulnerability has been resolved:

gpio: pch: use raw_spinlock_t for the register lock

pch_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.

This was confirmed on a PREEMPT_RT kernel with lockdep
(PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored
pch_irq_type()'s locking and drove it through the real genirq carrier
irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e.
the same __irq_set_trigger() edge that __setup_irq() takes for a
requested IRQ. With the original spin_lock_irqsave() edge lockdep
reported an invalid wait context, immediately followed by:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod
hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60
rt_spin_lock+0x3a/0x1c0
repro_irq_set_type+0x64/0xa0 [pch_repro]
__irq_set_trigger+0x69/0x140
irq_set_irq_type+0x78/0xd0

Switching the mirrored lock to raw_spinlock_t made both splats go away.

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, but all of those critical sections only perform
MMIO register accesses (ioread32()/iowrite32()) and
irq_set_handler_locked(); 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 raw_spinlock_t
in the irq startup path") and commit 90f0109019e6 ("gpio: eic-sprd: use
raw_spinlock_t in the irq startup path").
Published: 2026-08-15
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability arises from using a sleeping, RT‑maintained spinlock (spin_lock_irqsave) inside the pch_irq_type callback while the context is non‑sleepable and interrupts are disabled; on PREEMPT_RT kernels this leads the kernel to detect an invalid wait context and trigger a BUG, which can cause a panic or system reboot. The flaw does not provide direct code execution but can be leveraged to crash the system, resulting in a denial of service. The flaw is a misuse of concurrency primitives, specifically using a lock that can sleep where only a non‑sleepable lock should be used.

Affected Systems

The issue exists in the Linux kernel’s GPIO subsystem for PCH devices before the fix was merged (commit 16da33c and related changes). Any kernel version that does not contain this commit or the equivalent raw_spinlock_t patch is potentially affected, regardless of distribution or patch level; the CVE description does not enumerate specific releases, so all earlier kernels may be vulnerable.

Risk and Exploitability

The CVSS score is 5.5, the EPSS score is < 1%, and the vulnerability is not listed in CISA’s KEV catalog. The attack vector is local or privileged; an attacker with the ability to inject a kernel module or manipulate IRQ settings could trigger the buggy lock usage and cause a crash. Because the exploit requires privileged code and is not directly exploitable from user space, the overall risk is moderate, relying on the attacker’s ability to invoke built‑in IRQ type changes.

Generated by OpenCVE AI on August 21, 2026 at 23:27 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a kernel update that includes the commit converting the register lock to raw_spinlock_t (any kernel version containing commit 16da33c or later).
  • If an immediate kernel upgrade is not feasible, rebuild the kernel without PREEMPT_RT support so that the IRQ chip does not use spinning locks that may sleep, thereby eliminating the invalid context path.
  • As a temporary measure, audit and limit code that calls irq_set_irq_type() or other IRQ configuration APIs to avoid accidental triggering of the bug; restrict untrusted privileged users from performing such operations.

Generated by OpenCVE AI on August 21, 2026 at 23:27 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6466-1 linux security update
History

Fri, 21 Aug 2026 22:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-749

Fri, 21 Aug 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-413
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Wed, 19 Aug 2026 16:45:00 +0000


Sat, 15 Aug 2026 14:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-749

Sat, 15 Aug 2026 12:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_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. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. 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, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); 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 raw_spinlock_t in the irq startup path") and commit 90f0109019e6 ("gpio: eic-sprd: use raw_spinlock_t in the irq startup path").
Title gpio: pch: use raw_spinlock_t for the register lock
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-19T16:37:12.926Z

Reserved: 2026-08-15T05:44:03.902Z

Link: CVE-2026-74468

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-15T13:17:51.500

Modified: 2026-08-19T17:21:03.810

Link: CVE-2026-74468

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-08-15T00:00:00Z

Links: CVE-2026-74468 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-21T23:30:17Z

Weaknesses
  • CWE-413

    Improper Resource Locking