CVE-2026-64429 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
gpio: eic-sprd: use raw_spinlock_t in the irq startup path
sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->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() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep
BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv]
sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv]
__setup_irq.constprop.0+0xd/0x30 [vuln_msv]
Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability in question affects the Linux kernel's gpio eic-sprd driver where a critical race condition occurs during interrupt setup operations. This issue manifests when the sprd_eic_irq_unmask() function attempts to enable GPIO interrupts while simultaneously updating controller state through sprd_eic_update(). The problematic code path executes within the irq_startup() context which is not permitted to sleep, yet it utilizes a regular spinlock_t that becomes a sleeping lock under PREEMPT_RT configurations. This creates an incompatibility where the kernel's locking mechanism violates the non-sleeping constraints of interrupt chip callbacks.
The technical flaw stems from improper lock usage within the interrupt handling path of the Spreadtrum EIC (External Interrupt Controller) driver. When request_threaded_irq() is called followed by __setup_irq() and subsequently irq_startup(), the execution flow reaches sprd_eic_irq_unmask() which invokes sprd_eic_update() while holding a spinlock acquired through spin_lock_irqsave(). This locking mechanism becomes problematic in PREEMPT_RT environments where regular spinlocks are transformed into sleeping locks, violating kernel concurrency models. 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 sprd_eic_irq_unmask().
The operational impact of this vulnerability is significant as it can cause system crashes or deadlocks during interrupt initialization phases. When the kernel attempts to set up GPIO interrupts in a PREEMPT_RT configured system, the sleeping lock behavior triggers kernel warnings and potential system instability. The lockdep subsystem detects this violation by reporting "BUG: sleeping function called from invalid context" which indicates that a non-sleepable context is attempting to acquire a sleeping lock. This failure mode represents a fundamental violation of kernel locking principles where interrupt handlers must maintain strict non-blocking behavior.
The fix implemented addresses the core issue by converting the Spreadtrum EIC controller's lock from spinlock_t to raw_spinlock_t. This change is appropriate because the locked section only performs MMIO register updates that do not involve sleepable operations, making it safe for non-sleeping contexts. The raw_spinlock_t provides the necessary serialization without introducing sleeping behavior, ensuring interrupt chip callbacks maintain their required non-blocking characteristics. This solution aligns with CWE-367 principles regarding time-of-check to time-of-use vulnerabilities and follows ATT&CK technique T1068 by preventing privilege escalation through improper locking mechanisms in kernel space.
The mitigation strategy focuses on maintaining lock semantics while eliminating the problematic sleeping behavior that occurs under PREEMPT_RT configurations. By using raw_spinlock_t, the driver preserves the required mutual exclusion for MMIO register access without violating interrupt handler constraints. This approach ensures compatibility across different kernel configurations including both standard and PREEMPT_RT systems, preventing system instability during GPIO interrupt setup operations. The solution directly addresses the root cause by ensuring that interrupt chip callbacks maintain their non-sleeping nature while still providing adequate synchronization for hardware register updates.