CVE-2026-64374 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT
RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.
Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.
This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow.
The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.
The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT.
If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.
A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.
When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.
As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a critical race condition and live lock scenario affecting Linux kernel real-time scheduling mechanisms, specifically within the scheduler's handling of real-time tasks across multi-core systems. This issue manifests when non-preemptible real-time kernels attempt to utilize the RT_PUSH_IPI mechanism originally designed to optimize task migration in PREEMPT_RT environments. The root cause lies in the interaction between interrupt processing and real-time task scheduling, creating a pathological condition where system responsiveness degrades to complete lockup under specific workloads.
The technical flaw stems from the design of the RT_PUSH_IPI mechanism which was introduced to address performance bottlenecks in PREEMPT_RT systems where multiple CPUs attempting to migrate high-priority real-time tasks simultaneously would cause severe lock contention on runqueue locks. In non-PREEMPT_RT configurations, this same mechanism creates a dangerous interaction pattern when softirqs execute concurrently with real-time task scheduling operations. The kernel's scheduler logic determines that a CPU is overloaded when it contains waiting real-time tasks, triggering IPI-based migration attempts. However, when these migrations occur during softirq execution contexts, the system enters a state where IPI processing interferes so severely with softirq completion that the CPU becomes effectively unresponsive.
This vulnerability directly maps to CWE-409 which describes improper handling of concurrent operations and represents a classic live lock scenario where multiple threads or processes become blocked waiting for each other indefinitely. The issue manifests in the ATT&CK framework under T1486 - Data Encrypted for Impact, though more accurately represents system resource exhaustion through scheduling contention rather than direct data encryption. The operational impact is severe as it can cause complete system lockup on large multi-core systems performing heavy networking workloads where softirqs and real-time tasks are frequently interleaved.
The live lock occurs specifically when multiple CPUs in a system are simultaneously processing networking traffic that generates both high-priority real-time task wakeups and softirq execution contexts. The system enters a feedback loop where IPIs sent to overloaded CPUs cause further delays in softirq completion, preventing proper task scheduling and creating an infinite loop of IPI processing that starves the CPU of actual work execution. This condition is particularly problematic on systems with many cores where the probability of simultaneous scheduling events increases dramatically.
The mitigation strategy implemented by disabling RT_PUSH_IPI by default for non-PREEMPT_RT configurations addresses the fundamental architectural mismatch between the mechanism designed for preemptible real-time environments and the interrupt-driven nature of standard kernel operation. This solution prevents the problematic interaction while maintaining full functionality for systems that actually require PREEMPT_RT capabilities. The fix aligns with security best practices by reducing attack surface through disabling potentially harmful features in default configurations, ensuring that only systems specifically requiring the advanced scheduling optimizations actively utilize this mechanism.