In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Skip currently executing CPU in rtonextcpu()
CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVERTPUSHIPI enabled, they send IPIs to CPU0 to drive the execution of rtopushirqworkfunc. During pushrttask on CPU0, if nexttask->prio < rq->donor->prio, reschedcurr() sets NEEDRESCHED and after the push operation completes, CPU0 calls rtonextcpu(). Since only CPU0 is overloaded in this scenario, rtonextcpu() should ideally return -1 (no further IPI needed).
However, multiple CPUs invoking tellcputopush() during LB increments rd->rtoloopnext. Even when rd->rtocpu is set to -1, the mismatch between rd->rtoloop and rd->rtoloopnext forces rtonextcpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rtnrmigratory && rtnrtotal > 1), it gets reselected, causing CPU0 to queue irqwork to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pullrttasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.
The trigging scenario is as follows:
cpu0 cpu1 cpu2
pull_rt_task
tell_cpu_to_push
<------------irq_work_queue_on
rtopushirqworkfunc pushrttask reschedcurr(rq) pullrttask rtonextcpu tellcputopush <-------------------------- atomicinc(rtoloopnext) rd->rtoloop != next rtonextcpu irqworkqueueon rtopushirqwork_func
Fix redundant self-IPI by filtering the initiating CPU in rtonextcpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45919.json",
"cna_assigner": "Linux"
}