PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-45919 Linux CVE debrief

A logic flaw in the Linux kernel's real-time (RT) scheduler load balancing code can cause an overloaded CPU to enter an infinite self-IPI loop, resulting in a CPU hardlockup. The vulnerability exists in the `rto_next_cpu()` function used during RT task push operations when `HAVE_RT_PUSH_IPI` is enabled. When multiple CPUs trigger RT load balancing simultaneously, a race condition between `rd->rto_loop` and `rd->rto_loop_next` causes the overloaded CPU to repeatedly select itself for push operations, queueing irq_work to itself and sending self-IPIs continuously. The fix filters out the currently executing CPU in `rto_next_cpu()` to prevent redundant self-IPIs.

Vendor
Linux
Product
Unknown
CVSS
Unknown
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-27
Original CVE updated
2026-05-27
Advisory published
2026-05-27
Advisory updated
2026-05-27

Who should care

Organizations running Linux systems with real-time kernel configurations, particularly those with `CONFIG_HAVE_RT_PUSH_IPI` enabled and mixed RT/CFS workloads. Cloud providers hosting customer workloads with real-time scheduling requirements. Embedded systems and industrial control systems using PREEMPT_RT or similar real-time kernel patches.

Technical summary

The vulnerability resides in `kernel/sched/rt.c` in the RT scheduler's push task logic. When `HAVE_RT_PUSH_IPI` is configured, the `rto_push_irq_work_func` handles RT task pushing via IPIs. The `rto_next_cpu()` function selects target CPUs for push operations, but fails to exclude the currently executing CPU from selection. During concurrent load balancing operations, `tell_cpu_to_push()` increments `rd->rto_loop_next` across multiple CPUs, creating a mismatch with `rd->rto_loop`. This forces `rto_next_cpu()` to restart its search, and with the overloaded CPU still satisfying migration criteria (`rt_nr_migratory && rt_nr_total > 1`), it reselects itself. The CPU then queues irq_work to itself via `irq_work_queue_on()`, triggering `rto_push_irq_work_func` again in an infinite loop. Each iteration sends self-IPIs, eventually causing a CPU hardlockup detector trigger. The fix adds a CPU filter in `rto_next_cpu()` to skip the initiating CPU, breaking the self-IPI cycle.

Defensive priority

high

Recommended defensive actions

  • Apply kernel updates containing the fix for CVE-2026-45919 from your Linux distribution
  • Verify kernel version includes one of the referenced stable commits if running affected RT workloads
  • Monitor systems running real-time kernel configurations with HAVE_RT_PUSH_IPI enabled for unexpected CPU hardlockups
  • Consider temporarily disabling RT push IPI functionality if patches are unavailable and workload permits
  • Review scheduling configurations on systems hosting mixed RT and CFS workloads to reduce overload scenarios

Evidence notes

CVE description confirms this is a resolved Linux kernel vulnerability in the RT scheduler. Multiple stable kernel commits are referenced, indicating backports to various kernel versions. The vulnerability requires specific conditions: CPU-bound RT task, non-CPU-bound RT task, and CFS task stuck in kernel space on the same CPU, combined with `HAVE_RT_PUSH_IPI` enabled.

Official resources

2026-05-27