CVE-2026-64250 Overview
CVE-2026-64250 affects the Linux kernel LoongArch architecture. The vulnerability resides in the stop_this_cpu() function within the LoongArch SMP (Symmetric Multiprocessing) code path. When smp_send_stop() parks secondary CPUs during reboot, shutdown, or halt operations, the kernel marks each CPU offline for the scheduler via set_cpu_online(false) but never notifies Read-Copy-Update (RCU). RCU consequently waits indefinitely for quiescent states from CPUs that are spinning with interrupts disabled. Any irq_work_sync() call issued after smp_send_stop() blocks on a grace period that can never complete, hanging the reboot path.
Critical Impact
The flaw causes system reboot and shutdown operations to hang indefinitely due to RCU stalls on parked CPUs, resulting in a denial of service during system state transitions.
Affected Products
- Linux kernel LoongArch architecture (SMP configurations)
- Kernel versions containing commit 91840be8f710370 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT") without the corresponding LoongArch RCU fix
- Systems where arch_irq_work_has_interrupt() returns false on LoongArch
Discovery Timeline
- 2026-07-24 - CVE-2026-64250 published to NVD
- 2026-07-30 - Last updated in NVD database
Technical Details for CVE-2026-64250
Vulnerability Analysis
CVE-2026-64250 is a kernel synchronization defect [CWE-833 Deadlock class] in the LoongArch SMP shutdown path. When the kernel initiates a reboot or halt, smp_send_stop() iterates over secondary CPUs and calls stop_this_cpu() on each. That function disables interrupts, marks the CPU offline in the scheduler bitmap, and enters an infinite spin loop. The parked CPUs never pass through an RCU quiescent state again.
RCU tracks per-CPU state independently of the scheduler online mask. Without an explicit rcutree_report_cpu_dead() call, RCU continues to wait for quiescent states from these permanently spinning CPUs. Any subsequent grace-period requester blocks forever.
Root Cause
The root cause is a missing RCU state transition. LoongArch shuts down secondary CPUs directly from stop_this_cpu() rather than through the generic CPU-hotplug offline path, which normally issues rcutree_report_cpu_dead(). RCU therefore never learns that the CPU has stopped participating in read-side critical sections.
The defect became reachable after commit 91840be8f710370, which routed irq_work_sync() through synchronize_rcu() on architectures where arch_irq_work_has_interrupt() returns false. On such LoongArch configurations, any irq_work_sync() issued after smp_send_stop() waits on a grace period that cannot advance.
Attack Vector
The vulnerability manifests as a local denial of service triggered during system reboot, shutdown, or halt operations. It is not a remotely exploitable memory-safety issue. Observed symptoms include kernel warnings from kernel/irq_work.c:144 in irq_work_queue_on and rcu_sched stall reports naming the offline CPUs as blocking the current grace period. See the upstream commits (Kernel Git Commit a0269e92 and Kernel Git Commit 90e254f1) for the patch that calls rcutree_report_cpu_dead() after disabling interrupts, mirroring the generic CPU-hotplug offline path.
Detection Methods for CVE-2026-64250
Indicators of Compromise
- Kernel log entries reading WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on during reboot or shutdown.
- rcu: INFO: rcu_sched detected stalls on CPUs/tasks: messages naming offline CPUs as blocking the current grace period.
- Reboot, shutdown, or halt commands that fail to complete and leave the system in an unresponsive state after smp_send_stop().
Detection Strategies
- Inspect kernel release information with uname -a and compare against upstream LoongArch stable branches that include the fixing commits.
- Correlate dmesg output captured over serial console or pstore after a hung reboot to identify RCU stall signatures tied to offline CPUs.
- Audit vendor kernel changelogs for backports of the referenced fix commits on LoongArch builds.
Monitoring Recommendations
- Enable persistent kernel log capture (pstore, kdump, or remote syslog) on LoongArch hosts to preserve RCU stall traces across forced power cycles.
- Alert on rcu_sched detected stalls and irq_work_queue_on warning strings in centralized log pipelines.
- Track reboot durations on managed LoongArch fleets and flag hosts requiring forced power cycles to complete shutdown.
How to Mitigate CVE-2026-64250
Immediate Actions Required
- Apply the upstream LoongArch fix that calls rcutree_report_cpu_dead() from stop_this_cpu() once interrupts are disabled.
- Rebuild and deploy LoongArch kernels from a stable branch that includes the commits referenced in the NVD entry.
- Prioritize patching on LoongArch configurations where arch_irq_work_has_interrupt() returns false, since those systems are directly exposed.
Patch Information
The fix ports the MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying CPU to RCU in stop_this_cpu()") to LoongArch. It invokes rcutree_report_cpu_dead() after disabling interrupts in stop_this_cpu(), mirroring the generic CPU-hotplug offline path so RCU grace periods can complete. Merged variants are available in the following stable commits: 0833b2b, 1fa22de5, 262dadc6, 90e254f1, a0269e92, and f2539c56.
Workarounds
- No stable workaround exists that avoids patching the kernel; the defect is intrinsic to the LoongArch shutdown path.
- Where patching is not immediately possible, avoid running kernels that combine commit 91840be8f710370 on LoongArch builds where arch_irq_work_has_interrupt() returns false.
- Use out-of-band management (BMC, IPMI, or hypervisor console) to force power cycles on hosts that hang during reboot until the fix is deployed.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
