CVE-2026-64428 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
gpio: sch: use raw_spinlock_t in the irq startup path
sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
This issue was found by our static analysis tool and then manually reviewed against the current tree.
The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported:
BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]
__setup_irq.constprop.0+0xd/0x30 [vuln_msv]
Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability under analysis involves a critical concurrency issue within the Linux kernel's GPIO subsystem, specifically affecting the sch_gpio driver implementation. This flaw manifests when handling interrupt requests through the GPIO framework, where improper locking mechanisms create potential deadlock conditions in real-time kernel configurations. The root cause lies in the interaction between different lock types and the interrupt handling path during GPIO IRQ setup operations.
The technical flaw occurs within the irq_startup() function sequence where sch_irq_unmask() is invoked to enable GPIO interrupts, followed by sch_irq_mask_unmask() that updates controller state while holding sch->lock with spin_lock_irqsave(). This particular locking pattern becomes problematic because in PREEMPT_RT configurations, regular spinlock_t transforms into sleeping locks that cannot be acquired in interrupt contexts. The vulnerability specifically affects the GPIO interrupt chip implementation where the locking mechanism fails to maintain proper context constraints during interrupt setup operations.
The operational impact of this vulnerability is significant as it can lead to system deadlocks and kernel crashes when GPIO interrupts are configured in real-time kernel environments. The static analysis tool identified this issue by tracing the execution path from request_threaded_irq() through __setup_irq() to irq_startup() and ultimately to sch_irq_unmask(). Lockdep detection confirmed the problematic behavior where sleeping functions were called from invalid contexts, specifically during hardirq disabled periods. This creates a fundamental contradiction in lock semantics where the expected non-blocking locking behavior conflicts with actual sleepable lock acquisition.
The mitigation strategy involves converting the SCH controller lock from regular spinlock_t to raw_spinlock_t, which maintains the proper locking semantics required for interrupt contexts without introducing sleepable operations. This change preserves the existing GPIO direction and value callback behavior since those operations only modify MMIO-backed registers without requiring sleeping operations. The solution aligns with CWE-664, which addresses improper control of a resource through multiple access points, and follows ATT&CK technique T1059.006 for privilege escalation through kernel exploitation. The fix ensures that interrupt chip callbacks maintain their non-blocking nature while preserving the GPIO subsystem's locking contract for user-space operations.
This vulnerability demonstrates the complexity of maintaining proper locking semantics across different kernel configurations and execution contexts, particularly in PREEMPT_RT environments where traditional assumptions about lock behavior no longer hold. The resolution maintains system stability while ensuring correct operation of GPIO interrupt handling in both standard and real-time kernel deployments. The change represents a targeted fix that addresses the specific locking inconsistency without affecting broader GPIO functionality or introducing new attack surfaces.
The issue highlights the importance of context-aware locking in kernel development, where locks must be appropriately classified based on their usage contexts. In PREEMPT_RT systems, the distinction between sleeping and non-sleeping locks becomes critical for preventing deadlocks and maintaining system responsiveness. This vulnerability serves as a reminder that seemingly minor locking implementation details can have far-reaching consequences in real-time systems where timing and resource availability are paramount considerations.