CVE-2025-21816

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING<br /> <br /> hrtimers are migrated away from the dying CPU to any online target at<br /> the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers<br /> handling tasks involved in the CPU hotplug forward progress.<br /> <br /> However wakeups can still be performed by the outgoing CPU after<br /> CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being<br /> armed. Depending on several considerations (crystal ball power management<br /> based election, earliest timer already enqueued, timer migration enabled or<br /> not), the target may eventually be the current CPU even if offline. If that<br /> happens, the timer is eventually ignored.<br /> <br /> The most notable example is RCU which had to deal with each and every of<br /> those wake-ups by deferring them to an online CPU, along with related<br /> workarounds:<br /> <br /> _ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)<br /> _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)<br /> _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)<br /> <br /> The problem isn&amp;#39;t confined to RCU though as the stop machine kthread<br /> (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end<br /> of its work through cpu_stop_signal_done() and performs a wake up that<br /> eventually arms the deadline server timer:<br /> <br /> WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0<br /> CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted<br /> Stopper: multi_cpu_stop+0x0/0x120