CVE-2026-64250 in Linux
Summary
by MITRE • 07/24/2026
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Report dying CPU to RCU in stop_this_cpu()
This is a port of MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying CPU to RCU in stop_this_cpu()"). smp_send_stop() parks all secondary CPUs in stop_this_cpu(). And the function marks the CPU offline for the scheduler via set_cpu_online(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled.
As long as nothing waits for an RCU grace period after smp_send_stop() this is harmless, which is why it went unnoticed. However, since commit 91840be8f710370 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT"), irq_work_sync() calls synchronize_rcu() on architectures without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns false. Any irq_work_sync() issued in the reboot/shutdown/halt path after smp_send_stop() then blocks on a grace period that can never complete, hanging the reboot:
WARNING: CPU: 0 PID: 15 at kernel/irq_work.c:144 irq_work_queue_on ... rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP.
This issue needs some hacks to reproduce, and it was not noticed on LoongArch because arch_irq_work_has_interrupt() usually returns true.
Call rcutree_report_cpu_dead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. LoongArch shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/24/2026
The vulnerability described represents a critical race condition in the Linux kernel's LoongArch architecture implementation that affects the interaction between the Symmetric Multi-Processing (SMP) subsystem and the Read-Copy-Update (RCU) mechanism. This issue arises specifically within the stop_this_cpu() function where secondary CPUs are parked during system shutdown or reboot operations, creating a scenario where RCU cannot properly recognize that these CPUs have become non-responsive. The fundamental flaw occurs because while smp_send_stop() correctly marks CPUs as offline for the scheduler through set_cpu_online(false), it fails to notify RCU of this critical state change, leading to an inconsistent system state where RCU continues to expect quiescent states from CPUs that are spinning indefinitely with interrupts disabled.
The technical root cause stems from the architectural differences between LoongArch and other supported architectures like MIPS. In the MIPS implementation, a similar issue was addressed by properly integrating RCU notification mechanisms during CPU shutdown procedures, but this fix was not carried forward to LoongArch. The vulnerability becomes particularly dangerous when combined with recent kernel changes that introduced stricter RCU synchronization requirements, specifically commit 91840be8f710370 which modified irq_work_sync() behavior on PREEMPT_RT systems. This change causes irq_work_sync() to invoke synchronize_rcu() on architectures where arch_irq_work_has_interrupt() returns false, creating a deadlock scenario when shutdown operations occur after smp_send_stop() has been executed.
The operational impact of this vulnerability manifests as complete system hangs during reboot or shutdown procedures, particularly on LoongArch systems where the architecture's irq work implementation typically returns true for arch_irq_work_has_interrupt(). When the system attempts to synchronize RCU grace periods after stopping CPUs, the synchronization mechanism blocks indefinitely because RCU believes that the stopped CPUs are still participating in the grace period. The error messages indicate that RCU detects stalls on offline CPUs and reports that these CPUs are blocking current grace periods, creating a deadlock where the system cannot proceed with shutdown operations. This vulnerability affects systems running kernel versions where the problematic irq_work synchronization logic was introduced, making it particularly concerning for embedded systems or servers that rely on graceful shutdown procedures.
The mitigation strategy requires implementing the rcutree_report_cpu_dead() function call within stop_this_cpu() once interrupts are disabled, following the same pattern used in generic CPU-hotplug offline procedures. This approach ensures that RCU is properly notified of CPU death events even when CPUs are shut down outside of normal hotplug mechanisms, allowing grace periods to complete successfully and preventing the deadlock condition. The fix mirrors the established pattern from other architectures like MIPS where this specific issue was previously resolved, ensuring consistency across kernel implementations while maintaining the architectural integrity of LoongArch's shutdown procedures. This solution addresses the core architectural gap that existed between the CPU parking mechanism and RCU's expectation management, restoring proper system shutdown behavior and preventing the indefinite blocking that could occur during critical system operations.