CVE-2026-45919In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound…
Updated under an hour ago ()
Does this affect you?
It affects linux_kernel. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
In the Linux kernel, the following vulnerability has been resolved: sched/rt: Skip currently executing CPU in rto_next_cpu() 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 HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), 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 rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.
- CVSS
- 5.5 MEDIUM (v3.1, NVD)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Weakness (CWE)
- CWE-835
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Not given
- NVD analysis
- Undergoing Analysis
- Record last updated
- Jun 24, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
linux linux_kernel linux:linux_kernel | from 4.4.103 before 4.5; from 4.9.66 before 4.10; from 4.14.3 before 5.10.252; from 5.11 before 5.15.202; from 5.16 before 6.1.165; from 6.2 before 6.6.128; from 6.7 before 6.12.75; from 6.13 before 6.18.14; and 1 more ranges | NVD |
References
- https://git.kernel.org/stable/c/16ca9f3117e9a294646c897daf08a5ab546c711bpatch
- https://git.kernel.org/stable/c/3b3c672a66db3de3b40f8a7057864bc1f874ede3patch
- https://git.kernel.org/stable/c/52aeb1e07ec223caf212f036817976c98d2aa250patch
- https://git.kernel.org/stable/c/8ad5577b2d4acfd83f03d97a0aece2d18aac5f07patch
- https://git.kernel.org/stable/c/94894c9c477e53bcea052e075c53f89df3d2a33epatch
- https://git.kernel.org/stable/c/9f25edc5a20cb52a5abbf25f0724bb4732b81801patch
- https://git.kernel.org/stable/c/a6a73403733e86748421f2eeaf028c85683ef896patch
- https://git.kernel.org/stable/c/d57d0746276a88ea43a2cc62b849fd8a95e32e41patch
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.