CVE-2026-64248 in Linux
Summary
by MITRE • 07/24/2026
In the Linux kernel, the following vulnerability has been resolved:
MIPS: smp: report dying CPU to RCU in stop_this_cpu()
smp_send_stop() parks all secondary CPUs in stop_this_cpu(). 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. Since commit 91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT") however, irq_work_sync() calls synchronize_rcu() on architectures without an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns false. That is the asm-generic default used by MIPS. Any irq_work_sync() issued in the reboot/shutdown 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 was noticed on several Realtek MIPS switch SoCs (MIPS interAptiv) and came up during kernel bump downstream in OpenWrt from 6.18.33 to 6.18.34, after the backport of the patch to the 6.18 stable branch. The patch also has been backported all the way back to 6.1.
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. MIPS shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued. Reporting a dying CPU to RCU outside the regular hotplug offline path is not unprecedented: arm64 does the same in cpu_die_early(). There it is an exception for a CPU that was coming online and is aborting bringup, rather than the default shutdown action as on MIPS.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/24/2026
The vulnerability in question affects the Linux kernel's handling of symmetric multiprocessing on MIPS architectures, specifically within the smp_send_stop() function that parks secondary CPUs during system shutdown or reboot operations. This issue represents a critical race condition between the scheduler's CPU offline state management and the RCU (Read-Copy-Update) subsystem's expectation of quiescent states from all active CPUs. The flaw occurs in the stop_this_cpu() function where set_cpu_online(false) correctly marks the CPU as offline for scheduling purposes, but fails to notify RCU that this CPU is no longer capable of providing quiescent state updates.
The technical root cause stems from the mismatch between the CPU's actual operational state and its reported state within the RCU subsystem. When smp_send_stop() executes, it parks secondary CPUs in a loop where interrupts are disabled and the CPUs spin forever, yet RCU continues to await quiescent states from these CPUs. This creates a deadlock scenario where RCU grace periods cannot complete because they wait for confirmation that these parked CPUs have entered quiescent states, which never occurs. The vulnerability remained undetected for extended periods because typical system operations did not require waiting for RCU grace periods after smp_send_stop() had been invoked.
The exploitation of this vulnerability became possible with the introduction of commit 91840be8f710 that modified irq_work_sync() behavior on PREEMPT_RT systems. This change caused irq_work_sync() to invoke synchronize_rcu() on architectures where arch_irq_work_has_interrupt() returns false, which includes MIPS due to its asm-generic default implementation. The consequence is that any irq_work_sync() calls in the reboot/shutdown path following smp_send_stop() result in indefinite blocking as RCU waits for quiescent states from CPUs that are no longer responsive. This creates a system hang during shutdown operations manifesting as rcu_sched stall warnings indicating that offline CPUs are blocking current grace periods.
This vulnerability impacts specific MIPS-based systems, particularly Realtek MIPS switch SoCs (MIPS interAptiv processors) commonly found in networking equipment and embedded devices. The issue was identified during kernel version upgrades in OpenWrt distributions when backporting patches from kernel 6.18.34 to 6.18.33, demonstrating how seemingly isolated kernel changes can create cascading effects in specific hardware platforms. The problem affects systems where the CPU shutdown process bypasses the standard CPU-hotplug mechanism, requiring explicit RCU notification for proper system state management.
The proposed fix involves calling rcutree_report_cpu_dead() once interrupts are disabled within the stop_this_cpu() function, aligning with the generic CPU-hotplug offline path behavior. This approach mirrors implementations used in other architectures like arm64 where similar situations require explicit RCU notifications during CPU shutdown operations. The solution ensures that RCU recognizes these parked CPUs as dead and stops waiting for their quiescent state updates, allowing grace periods to complete successfully. This fix addresses the specific case where MIPS systems shut down all CPUs without traversing the regular hotplug offline path, which is a valid operational mode for embedded systems but requires explicit RCU coordination to prevent deadlock conditions.
This vulnerability type corresponds to CWE-691, which covers insufficient control flow management and represents a failure in proper synchronization between system subsystems. The issue also relates to ATT&CK technique T1490, specifically "Inhibit System Recovery" through the use of system shutdown or reboot mechanisms to create persistent operational failures. The fix ensures proper resource cleanup and prevents system hang conditions during critical operations while maintaining the intended behavior of CPU parking during shutdown sequences across MIPS architectures.