CVE-2026-64374

What it actually does

This Linux kernel scheduler flaw can cause a CPU livelock on non-PREEMPT_RT kernels when real-time task migration uses RT_PUSH_IPI under heavy softirq activity, such as high network interrupt load. The affected CPU can be repeatedly interrupted by inter-processor interrupts while attempting to schedule queued real-time tasks, preventing it from returning to task context and making forward progress. The practical technical result is denial of service through severe CPU starvation, scheduler stalls, latency spikes, and potential system instability or watchdog-triggered recovery.

Why it matters to the business

Successful exploitation or accidental triggering can degrade or interrupt availability of Linux systems, especially large multi-CPU hosts handling heavy network traffic and real-time workloads. Business consequences may include service outages, missed real-time processing deadlines, packet loss, application timeouts, degraded customer-facing services, and emergency reboots. Although the current EPSS is low and there is no known CISA KEV listing or mature public exploit indicated, kernel availability bugs should be prioritized for systems running latency-sensitive, network-heavy, or real-time workloads.

How an attack unfolds

An attacker or workload does not gain code execution or data access through this flaw; the impact is availability. Exploitation involves creating conditions where a non-PREEMPT_RT Linux kernel is under heavy softirq activity, commonly from high-volume networking, while real-time tasks are repeatedly awakened and queued. Other CPUs observe an overloaded runqueue and send RT_PUSH_IPI requests to the CPU that should schedule those real-time tasks. Because softirqs are executing in interrupt context on non-PREEMPT_RT kernels, the CPU may be unable to complete the scheduling transition. Repeated IPIs further slow softirq completion, creating a livelock where the CPU remains overloaded and does not make normal forward progress. In a real attack, remote traffic may contribute to the necessary network softirq pressure, but reliable exploitation generally depends on the victim system’s kernel configuration, CPU topology, scheduler behavior, workload, and presence of real-time tasks.

How to fix it

Apply a vendor kernel update that includes the upstream fix making RT_PUSH_IPI default off for non-PREEMPT_RT kernels. Because no specific affected package list or fixed versions were provided, use the fixed kernel versions published by the relevant Linux distribution or appliance vendor and prioritize production systems with high network throughput, large CPU counts, or real-time workloads. If immediate patching is not possible, reduce exposure by limiting untrusted high-volume network traffic, applying rate limits, isolating real-time workloads from internet-facing traffic paths, reducing avoidable RT task wakeups, and monitoring for softirq/IPI saturation. Kernel configuration or runtime mitigation options may vary by distribution; follow vendor guidance rather than manually changing scheduler internals unless validated in a test environment.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the scheduler fix for RT_PUSH_IPI behavior on non-PREEMPT_RT kernels. Validate by checking the installed kernel package against vendor advisories, rebooting into the corrected kernel, and confirming the running kernel version with standard OS inventory tooling. For high-risk platforms, run a controlled regression test that combines expected production network load with real-time task activity and verify that CPU livelock, excessive scheduler latency, watchdog warnings, and abnormal IPI growth do not occur. Also confirm that monitoring shows normal softirq processing, stable CPU utilization, and no recurring kernel scheduler or RCU stall messages after remediation.

Typical attack path

1. Identify or target a Linux system running an affected non-PREEMPT_RT kernel with many CPUs and real-time or latency-sensitive workloads.
2. Generate heavy network activity or otherwise induce sustained softirq processing on one or more CPUs.
3. Cause or wait for repeated wakeups of real-time tasks so the scheduler marks CPUs as having queued higher-priority RT work.
4. Trigger RT migration behavior where other CPUs repeatedly send inter-processor interrupts to overloaded CPUs.
5. Sustain the workload until softirq processing and repeated IPIs prevent the target CPU from returning to task context.
6. Observe denial-of-service effects such as CPU livelock, latency spikes, soft lockup warnings, packet loss, application hangs, or system instability.

How to detect it

This issue is a denial-of-service condition and does not inherently create files, accounts, persistence, or command-execution artifacts. Detection should focus on signs that a host experienced scheduler livelock or severe kernel availability degradation. Review kernel logs, system journals, hypervisor console logs, crash dumps, performance telemetry, and network monitoring around outage windows. Look for soft lockup, hard lockup, RCU stall, hung task, watchdog, excessive interrupt, and ksoftirqd saturation messages. Compare /proc/interrupts, CPU utilization, softirq counters, packet rates, and real-time task activity during the incident if historical telemetry is available. Network telemetry may show unusually high packet rates preceding the outage, but traffic alone is not a reliable indicator because the bug depends on kernel configuration and workload conditions. There are no known threat actors or public exploitation campaigns reported in the provided data.

• watchdog: BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• rcu: INFO: rcu_preempt detected stalls on CPUs/tasks
• rcu: INFO: rcu_sched detected stalls on CPUs/tasks
• INFO: task
• blocked for more than
• softirq
• ksoftirqd
• NET_RX
• NET_TX
• IPI
• rescheduling interrupts
• smp_call_function
• sched/rt
• rt_push
• RT_PUSH_IPI

What your security team should do

• Inventory Linux systems running real-time workloads, high-throughput networking, or large CPU counts, and prioritize them for kernel update validation.
• Track vendor kernel advisories for this issue and deploy the fixed kernel as soon as it is available for each supported distribution or appliance.
• Prioritize patching for externally reachable systems where remote traffic could contribute to high softirq pressure.
• Add monitoring for kernel soft lockups, RCU stalls, abnormal IPI rates, ksoftirqd saturation, and unexplained service latency spikes.
• If patching is delayed, apply network rate limiting, traffic filtering, or workload isolation to reduce the chance of sustained softirq overload.
• After patching, reboot into the fixed kernel and verify the active kernel version rather than only confirming package installation.
• Review incident data for recent unexplained CPU stalls or watchdog events on network-heavy Linux hosts, while recognizing that this vulnerability does not produce strong file-based indicators.