CVE-2026-45919

What it actually does

This is a local Linux kernel denial-of-service flaw in the real-time scheduler load-balancing path. Under a specific CPU scheduling condition, the kernel can repeatedly select the currently executing overloaded CPU as the next target for RT push work, causing redundant self-directed inter-processor interrupts. The resulting infinite self-IPI loop can keep the CPU in interrupt handling long enough to trigger a hard lockup, making the system unresponsive and potentially requiring a reboot. The flaw impacts availability only; it does not directly provide confidentiality or integrity compromise.

Why it matters to the business

A local user or workload capable of creating the required real-time scheduling pressure could crash or hang affected Linux systems, interrupting applications, virtual machines, containers, or infrastructure services running on those hosts. The risk is most relevant for multi-user systems, shared compute platforms, latency-sensitive workloads, and environments where untrusted or semi-trusted users can run processes with real-time scheduling privileges. This issue is not known to be in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity in the provided data, so urgency is lower than for remotely exploitable kernel flaws but still important for availability-sensitive systems.

How an attack unfolds

An attacker first obtains local code execution on an affected Linux host. They then create or influence a scheduling scenario involving CPU-bound and non-CPU-bound real-time tasks, along with other tasks that cause RT load-balancing activity across CPUs. When other CPUs attempt to pull or push real-time tasks, the vulnerable scheduler logic can cause the overloaded CPU to queue RT push work to itself. Because the currently executing CPU is not skipped by the vulnerable rto_next_cpu() path, the same CPU can be repeatedly reselected, producing continuous self-IPIs. If the condition persists, the CPU can enter a hard lockup state, causing severe system degradation, service outage, or a forced reboot.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the scheduler fix for the RT load-balancing path, specifically the change that skips the currently executing CPU in rto_next_cpu(). No exact fixed package versions were provided, so use distribution advisories for the applicable kernel package and reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by limiting which users, containers, and services can create real-time scheduled tasks; review and restrict CAP_SYS_NICE; set conservative RLIMIT_RTPRIO values; avoid granting untrusted workloads real-time scheduling privileges; and use workload isolation for systems running RT-sensitive tasks. Availability-critical systems should also have watchdog, HA, and crash-dump procedures validated because exploitation can require reboot or failover recovery.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a build containing the fix. Validate with distribution package metadata, kernel changelogs, or vendor advisory references for the scheduler RT patch titled similar to 'sched/rt: Skip currently executing CPU in rto_next_cpu()'. After patching and rebooting, verify `uname -r` matches the intended fixed kernel and that package managers do not show the old vulnerable kernel as the active boot default. For mitigation validation, audit real-time scheduling permissions by checking users and services with CAP_SYS_NICE, nonzero real-time priority limits, privileged containers, or service unit settings that permit real-time scheduling. In test environments only, controlled scheduler stress testing can be used to confirm that RT overload scenarios no longer produce self-IPI storms or hard lockups.

Typical attack path

1. Gain local access to an affected Linux system, such as through a shell, compromised service account, container escape-adjacent workload capability, or authorized but malicious user session.
2. Obtain the ability to run or influence real-time scheduled tasks, commonly requiring appropriate scheduling privileges, limits, or capabilities such as permission to use SCHED_FIFO/SCHED_RR.
3. Create CPU pressure using a mix of CPU-bound RT tasks, non-CPU-bound RT tasks, and other tasks so that one CPU becomes overloaded while other CPUs trigger RT load balancing.
4. Cause repeated RT push/pull activity across CPUs so the vulnerable scheduler path invokes rto_next_cpu() and reselects the same currently executing CPU.
5. Maintain the overload condition until repeated self-IPIs trigger a CPU hard lockup.
6. Leverage the resulting hang or crash to disrupt services, force failover, or require manual recovery.

How to detect it

There may be no clean application-layer indicator because exploitation manifests as a local kernel availability failure. Review persistent system logs, kernel ring buffers, netconsole/serial console output, hypervisor console logs, kdump vmcores, and monitoring alerts for hard lockups, watchdog events, repeated interrupt activity, and scheduler stack traces. Look shortly before the lockup for evidence of local users or workloads creating real-time tasks, changing scheduling policy, using tools such as chrt/taskset/stress-style CPU loaders, launching privileged containers, or running processes with CAP_SYS_NICE. Audit authentication, sudo, auditd, container runtime, and EDR telemetry for local execution by unexpected users immediately before the outage. In vmcores or kernel stack traces, prioritize evidence showing repeated execution in RT scheduler functions such as rto_push_irq_work_func(), rto_next_cpu(), push_rt_task(), pull_rt_task(), tell_cpu_to_push(), irq_work_queue_on(), and resched_curr(). Distinguish exploitation from benign RT workload instability by correlating the hard lockup with unauthorized local activity or unusual real-time scheduling changes.

• NMI watchdog: Watchdog detected hard LOCKUP on cpu
• watchdog: Watchdog detected hard LOCKUP on cpu
• Kernel panic - not syncing: Hard LOCKUP
• BUG: hard LOCKUP
• rto_push_irq_work_func
• rto_next_cpu
• push_rt_task
• pull_rt_task
• tell_cpu_to_push
• irq_work_queue_on
• resched_curr
• sched_setscheduler
• SCHED_FIFO
• SCHED_RR
• CAP_SYS_NICE
• chrt --fifo
• chrt --rr
• kernel.watchdog
• soft lockup - CPU#

What your security team should do

• Prioritize patching multi-user Linux hosts, shared compute nodes, container hosts, real-time workload systems, and availability-critical servers running affected kernels.
• Identify systems where untrusted or semi-trusted users can execute local code or run containers with elevated scheduling permissions.
• Restrict CAP_SYS_NICE, privileged containers, and real-time priority limits to only services that explicitly require them.
• Monitor for kernel hard lockup events, unexpected reboots, and scheduler-related stack traces involving rto_next_cpu(), rto_push_irq_work_func(), push_rt_task(), pull_rt_task(), or irq_work_queue_on().
• Ensure crash dumps, persistent journaling, and remote log forwarding are enabled so evidence is retained after a lockup or reboot.
• Track distribution-specific kernel advisories because no exact fixed versions were provided in the input.
• Treat confirmed unexplained hard lockups on affected kernels with RT scheduling activity as potential exploitation or abuse until workload causes are ruled out.