CVE-2026-45919: Linux Kernel Scheduler DoS Vulnerability

CVE-2026-45919 Overview

CVE-2026-45919 is a Linux kernel vulnerability in the real-time (RT) scheduler's load-balancing logic. The flaw lives in rto_next_cpu() within kernel/sched/rt.c, where the initiating CPU is not excluded from the overload search. When an overloaded CPU hosts a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space, it can queue irq_work to itself and send repeated self-IPIs. The resulting infinite self-interrupt loop produces a CPU hardlockup. The maintainers have resolved the issue by filtering the initiating CPU in rto_next_cpu().

Critical Impact

A local condition involving concurrent RT load balancing can drive a CPU into an infinite self-IPI loop, triggering a hardlockup and denial of service on affected Linux systems.

Affected Products

• Linux kernel (mainline) prior to the fix in rto_next_cpu()
• Stable Linux kernel branches receiving the backports referenced by the kernel.org commits
• Linux distributions shipping affected stable kernels with HAVE_RT_PUSH_IPI enabled

Discovery Timeline

• 2026-05-27 - CVE-2026-45919 published to NVD
• 2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45919

Vulnerability Analysis

The defect resides in the RT scheduler's push/pull load-balancing path. When other CPUs transition from RT to non-RT tasks, RT load balancing fires. With HAVE_RT_PUSH_IPI enabled, those CPUs call tell_cpu_to_push() and send IPIs to an overloaded CPU to drive rto_push_irq_work_func.

During push_rt_task on the overloaded CPU, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED. After the push completes, the CPU calls rto_next_cpu() to find the next overloaded CPU. In a scenario where only one CPU is overloaded, that call should return -1.

Root Cause

Multiple CPUs invoking tell_cpu_to_push() increment rd->rto_loop_next atomically. 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. The still-overloaded CPU (satisfying rt_nr_migratory && rt_nr_total > 1) is reselected. It queues irq_work to itself and sends self-IPIs repeatedly. This is a denial-of-service condition rooted in a scheduler race [CWE-362-class behavior] producing continuous self-interrupts and a hardlockup.

Attack Vector

The condition is local and requires specific scheduling pressure: a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space on the same CPU, combined with other CPUs running pull_rt_task(). The trigger sequence flows as follows: CPU1 and CPU2 issue pull_rt_task and tell_cpu_to_push, sending IPIs to CPU0. CPU0 runs rto_push_irq_work_func and push_rt_task, calls resched_curr(rq), then rto_next_cpu. While CPU0 processes, CPU2 increments rto_loop_next via atomic_inc. Because rd->rto_loop != next, CPU0 re-enters rto_next_cpu, queues irq_work_queue_on to itself, and re-enters rto_push_irq_work_func, looping indefinitely.

No verified public exploit code is available. See the upstream patches at Kernel Git Commit 16ca9f3117e and Kernel Git Commit 94894c9c47 for technical details of the fix.

Detection Methods for CVE-2026-45919

Indicators of Compromise

• Kernel watchdog or NMI hardlockup messages naming a single CPU stuck servicing interrupts
• Sustained 100% system-time utilization on one CPU with elevated irq_work activity in /proc/interrupts
• High counts of sched_rt push/pull events under tracefs (sched_switch, irq_work_entry) with the same CPU as both source and destination

Detection Strategies

• Trace rto_push_irq_work_func and rto_next_cpu invocations with ftrace or perf to identify recursive self-queueing on a single CPU
• Monitor /proc/interrupts for an abnormal growth in IPI counters on a single CPU paired with kernel softlockup or hardlockup warnings
• Correlate scheduler tracepoints (sched:sched_switch, irq_work:irq_work_entry) against RT task placement to spot overload patterns matching the trigger scenario

Monitoring Recommendations

• Enable kernel.hardlockup_panic and kernel.softlockup_panic in lab fleets to fail fast and capture crash dumps for triage
• Collect kernel logs centrally and alert on watchdog: Watchdog detected hard LOCKUP on cpu messages
• Track running kernel versions across the fleet and flag hosts still on pre-patch stable branches referenced by the kernel.org commits

How to Mitigate CVE-2026-45919

Immediate Actions Required

• Identify hosts running affected stable Linux kernel branches with HAVE_RT_PUSH_IPI enabled and prioritize them for patching
• Apply the upstream fix that filters the initiating CPU in rto_next_cpu() from your distribution vendor as it becomes available
• Validate RT workload configurations and avoid pinning combinations of CPU-bound RT, non-CPU-bound RT, and long-running CFS kernel work to the same CPU until patched

Patch Information

The fix has been merged into mainline and backported across stable trees. Reference the commits at Kernel Git Commit 3b3c672a66d, Kernel Git Commit 52aeb1e07e, Kernel Git Commit 8ad5577b2d, Kernel Git Commit 9f25edc5a2, Kernel Git Commit a6a7340373, and Kernel Git Commit d57d074627. The change modifies rto_next_cpu() to skip the currently executing CPU during the overload search, eliminating the self-IPI loop.

Workarounds

• Redistribute RT workloads using taskset, cgroups, or sched_setaffinity() so that the triggering combination does not coexist on one CPU
• Disable or reconfigure RT push IPI behavior in controlled environments where the kernel build options permit
• Reduce RT priority pressure by tuning sched_rt_runtime_us and sched_rt_period_us to limit RT bandwidth on suspect hosts

# Identify running kernel and check for the fix
uname -r

# Inspect IPI counters per CPU to spot anomalies
grep -E 'IPI|RES|CAL' /proc/interrupts

# Enable hardlockup panic for faster fault capture (test systems only)
sysctl -w kernel.hardlockup_panic=1
sysctl -w kernel.softlockup_panic=1

# Constrain an RT workload to a dedicated CPU set
taskset -cp 2,3 <pid>