CVE-2026-64248
Beschrijving NL
In de Linux kernel is de volgende kwetsbaarheid verholpen:
MIPS: smp: rapporteer stervende CPU aan RCU in stop_this_cpu()
smp_send_stop() parkeert alle secundaire CPU's in stop_this_cpu(). De functie
markeert de CPU offline voor de planner via set_cpu_online(false) maar
informeert RCU nooit, dus RCU blijft een rusttoestand van CPU's verwachten
die nu voor altijd draaien met onderbrekingen uitgeschakeld. Zolang er niets wacht op een RCU respijtperiode na smp_send_stop()
dit is onschadelijk, daarom bleef het onopgemerkt. Sinds commit
91840be8f710 ("irq_work: Fix use-after-free in irq_work_single() on PREEMPT_RT")
irq_work_sync() echter synchronize_rcu () aanroept op architecturen zonder
an irq_work self-IPI, i.e. where arch_irq_work_has_interrupt() returns
false. Dat is de asm-generieke standaard die door MIPS wordt gebruikt. Elke irq_work_sync()
uitgegeven in het pad voor opnieuw opstarten/afsluiten na smp_send_stop() en blokkeert vervolgens op
een respijtperiode die nooit kan worden voltooid, waarbij de reboot wordt opgehangen:
WAARSCHUWING: CPU: 0 PID: 15 bij kernel/irq_work.c:144 irq_work_queue_on
... rcu: INFO: rcu_sched gedetecteerde stallen op CPU's/taken:
rcu: Offline CPU 1 blokkeert huidige GP. rcu: Offline CPU 2 blokkeert huidige GP. rcu: Offline CPU 3 blokkeert huidige GP. Dit probleem werd opgemerkt op verschillende Realtek MIPS switch SoC's (MIPS
interAptiv) en kwam tijdens kernel bump stroomafwaarts in OpenWrt van
6.18.33 tot 6.18.34, na de backport van de patch naar de 6.18 stal
tak. De patch is ook helemaal teruggeporteerd naar 6.1. Bel rcutree_report_cpu_dead() zodra onderbrekingen zijn uitgeschakeld, waarbij de
generieke CPU-hotplug offline pad, zodat RCU stopt met wachten op de geparkeerde CPU's
en respijtperiodes kunnen nog steeds worden voltooid. MIPS schakelt hier alle CPU's uit
zonder het CPU-hotplug-mechanisme te doorlopen, dus dit rapport is niet
anders uitgegeven. Een stervende CPU melden aan RCU buiten de reguliere hotplug
offline pad is niet ongekend: arm64 doet hetzelfde in cpu_die_early(). Er is een uitzondering voor een CPU die online kwam en wordt afgebroken
brengen, in plaats van de standaard uitschakelactie zoals op MIPS.
Origineel (Engels) tonen
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.