CVE-2026-64429

What it actually does

This vulnerability is a Linux kernel real-time locking bug in the Spreadtrum EIC GPIO interrupt controller driver. During IRQ setup, sprd_eic_irq_unmask() can call sprd_eic_update() from a non-sleepable interrupt-startup path. On PREEMPT_RT kernels, a normal spinlock_t may become a sleeping lock, so taking it in this context can trigger a "sleeping function called from invalid context" kernel warning or failure. The practical technical impact is local denial of service or system instability on affected kernels and hardware/configurations using the Spreadtrum EIC controller with PREEMPT_RT behavior. The intended fix is to use raw_spinlock_t for the controller lock because the protected section only serializes MMIO register updates and must not sleep.

Why it matters to the business

Systems running affected Linux kernels on hardware that uses the Spreadtrum EIC GPIO interrupt controller may experience crashes, lockups, or degraded availability when IRQs are initialized. This is most relevant for embedded, mobile, telecom, industrial, or real-time Linux deployments where PREEMPT_RT is enabled. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, availability-sensitive real-time systems should still prioritize kernel updates during the next appropriate maintenance window.

How an attack unfolds

An attacker or unprivileged workload would need a way to cause the vulnerable driver path to request and initialize an IRQ associated with the Spreadtrum EIC GPIO controller. During IRQ setup, the kernel follows the request_threaded_irq() to __setup_irq() to irq_startup() path. irq_startup() invokes the irqchip unmask callback, which reaches sprd_eic_irq_unmask(). That function enables the GPIO interrupt and updates controller state via sprd_eic_update(). On PREEMPT_RT kernels, the regular spinlock used by the driver can behave as a sleeping lock, which is invalid in the IRQ startup context. This can trigger a lockdep splat, kernel warning, BUG condition, or system instability, resulting in denial of service. Exploitation is constrained by hardware, kernel configuration, and the attacker's ability to influence IRQ setup, so this is not expected to be a remotely exploitable vulnerability in typical deployments.

How to fix it

Apply the vendor-provided Linux kernel update that changes the Spreadtrum EIC controller lock from spinlock_t to raw_spinlock_t in the IRQ startup path. If consuming kernels from a distribution, SoC vendor, Android BSP, embedded Linux vendor, or long-term support branch, upgrade to the first fixed kernel package provided by that supplier. If maintaining a custom kernel, backport the upstream fix for the gpio: eic-sprd driver so that the lock used around MMIO register updates is a raw spinlock. Where immediate patching is not possible, reduce exposure by disabling unused Spreadtrum EIC GPIO functionality, avoiding PREEMPT_RT kernels on affected hardware where feasible, restricting local access to interfaces that can trigger GPIO IRQ setup, and scheduling controlled reboots or failover plans for availability-critical devices.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the patched gpio/eic-sprd driver code using raw_spinlock_t for the Spreadtrum EIC controller lock. For source-based builds, inspect the relevant driver implementation and confirm raw_spin_lock_irqsave/raw_spin_unlock_irqrestore usage for the EIC lock path. For packaged kernels, confirm the installed kernel version or vendor advisory states that CVE-2026-64429 is fixed. On representative hardware, run a controlled IRQ initialization test for the Spreadtrum EIC GPIO controller on a PREEMPT_RT kernel and verify that dmesg or journal logs no longer show "BUG: sleeping function called from invalid context" with stack frames involving sprd_eic_irq_unmask(), sprd_eic_update(), __setup_irq(), or irq_startup().

Typical attack path

1. Identify a Linux system using the Spreadtrum EIC GPIO interrupt controller on an affected kernel configuration, especially PREEMPT_RT.
2. Gain local code execution or control over a component capable of causing the relevant GPIO IRQ to be requested or initialized.
3. Trigger IRQ registration through a path such as request_threaded_irq().
4. Cause irq_startup() to invoke sprd_eic_irq_unmask() during interrupt setup.
5. Reach sprd_eic_update(), where the driver attempts to take a sleepable spinlock in a non-sleepable context.
6. Induce a kernel BUG, lockdep failure, crash, or instability that affects system availability.

How to detect it

Look for evidence of kernel warnings, lockdep reports, BUG messages, panics, or unexpected reboots around GPIO IRQ setup on systems using the Spreadtrum EIC driver. Primary log sources are dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, persistent pstore/ramoops crash logs, kernel crash dumps, and embedded device watchdog/reset telemetry. Search for stack traces containing sprd_eic_update, sprd_eic_irq_unmask, irq_startup, __setup_irq, request_threaded_irq, and messages indicating a sleeping function was called from invalid context. Because this issue does not have known public exploitation or stable remote indicators, detection should focus on local crash artifacts and repeated kernel log patterns rather than network IOCs. Correlate events with recent driver loads, GPIO device initialization, peripheral attach events, service starts that request GPIO interrupts, or suspicious local activity capable of manipulating hardware interfaces.

• BUG: sleeping function called from invalid context
• sleeping function called from invalid context
• sprd_eic_irq_unmask
• sprd_eic_update
• request_threaded_irq
• __setup_irq
• irq_startup
• spin_lock_irqsave(&sprd_eic->lock)
• sprd_rt_spin_lock_irqsave
• gpio: eic-sprd
• hardirqs last disabled at
• lockdep

What your security team should do

• Inventory Linux systems using Spreadtrum/Unisoc EIC GPIO controllers, especially embedded and real-time deployments.
• Prioritize patching PREEMPT_RT kernels and availability-critical devices where the affected driver is enabled.
• Obtain fixed kernels from the relevant Linux distribution, SoC vendor, BSP provider, device OEM, or internal kernel-maintenance team.
• For custom kernels, backport the driver change from spinlock_t to raw_spinlock_t and rebuild affected images.
• Monitor kernel logs for lockdep or BUG messages referencing sleeping locks in the sprd_eic IRQ startup path.
• Restrict local shell, debug, GPIO, and device-management access on affected appliances until patched.
• Include regression testing for GPIO interrupt setup on PREEMPT_RT builds before production rollout.