CVE-2026-45919

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Skip currently executing CPU in rto_next_cpu()<br /> <br /> CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound<br /> RT task, and a CFS task stuck in kernel space. When other CPUs switch from<br /> RT to non-RT tasks, RT load balancing (LB) is triggered; with<br /> HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution<br /> of rto_push_irq_work_func. During push_rt_task on CPU0,<br /> if next_task-&gt;prio donor-&gt;prio, resched_curr() sets NEED_RESCHED<br /> and after the push operation completes, CPU0 calls rto_next_cpu().<br /> Since only CPU0 is overloaded in this scenario, rto_next_cpu() should<br /> ideally return -1 (no further IPI needed).<br /> <br /> However, multiple CPUs invoking tell_cpu_to_push() during LB increments<br /> rd-&gt;rto_loop_next. Even when rd-&gt;rto_cpu is set to -1, the mismatch between<br /> rd-&gt;rto_loop and rd-&gt;rto_loop_next forces rto_next_cpu() to restart its<br /> search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory<br /> &amp;&amp; rt_nr_total &gt; 1), it gets reselected, causing CPU0 to queue irq_work to<br /> itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and<br /> other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,<br /> which triggers a CPU hardlockup due to continuous self-interrupts.<br /> <br /> The trigging scenario is as follows:<br /> <br /> cpu0 cpu1 cpu2<br /> pull_rt_task<br /> tell_cpu_to_push<br />