Description
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.
Published: 2026-07-25
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel RT scheduler contains logic that pushes high‑priority real‑time tasks to other CPUs via inter‑processor interrupts (IPIs). When the kernel is compiled without the PREEMPT_RT patch, this push mechanism can incorrectly schedule tasks while a softirq is still executing, causing the CPU to repeatedly receive IPIs. The cycle prevents the softirq from returning to task context, locking the CPU in an IPI handling loop and producing latency spikes of up to 500 µs. The flaw is a race condition in RT task migration that results in a denial of service for workloads sensitive to CPU availability.

Affected Systems

All Linux kernel builds that include the RT_PUSH_IPI feature, including mainstream stable releases and custom kernels with real‑time scheduling, are impacted when compiled without the PREEMPT_RT patch. The feature is enabled by default in these builds, so any mainstream kernel that does not use the PREEMPT_RT patch will be vulnerable unless the RT_PUSH_IPI configuration is disabled. Kernels that are compiled with PREEMPT_RT enabled are not affected because the IPI logic is handled differently.

Risk and Exploitability

The CVSS score of 7.5 and an EPSS score of less than 1 % indicate a moderate severity but low likelihood of exploitation. The vulnerability does not provide a remote trigger; it requires a specific environment in which heavy network traffic generates frequent softirqs and the system runs real‑time tasks. The lack of listing in the CISA KEV catalog further supports a low threat level. Attackers would need privileged access or a kernel module to force the required load pattern, so the risk is primarily performance degradation under a narrow set of conditions rather than widespread exploitation.

Generated by OpenCVE AI on August 4, 2026 at 14:35 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Rebuild or configure the kernel with RT_PUSH_IPI disabled when PREEMPT_RT is not enabled (e.g., set the feature to default off or undefine the corresponding configuration option).
  • Apply the latest stable kernel revision that incorporates this change; consult the vendor's release notes or kernel commit logs for confirmation.
  • If the system uses the PREEMPT_RT patch, leave RT_PUSH_IPI enabled to preserve the performance benefits for real‑time workloads.
  • Monitor CPU utilization and softirq latency; if frequent softirqs coincide with RT task scheduling, consider reducing the softirq load or adjusting RT task priorities.

Generated by OpenCVE AI on August 4, 2026 at 14:35 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4717-1 linux security update
Debian DLA Debian DLA DLA-4720-1 linux security update
Debian DLA Debian DLA DLA-4723-1 linux-6.1 security update
Debian DLA Debian DLA DLA-4724-1 linux-6.12 new package
History

Mon, 03 Aug 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Thu, 30 Jul 2026 00:15:00 +0000


Mon, 27 Jul 2026 05:15:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}


Sun, 26 Jul 2026 02:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Sat, 25 Jul 2026 09:30:00 +0000

Type Values Removed Values Added
Description 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.
Title sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-05T12:41:11.896Z

Reserved: 2026-07-19T15:36:31.784Z

Link: CVE-2026-64374

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-07-25T10:17:20.433

Modified: 2026-08-11T15:01:50.637

Link: CVE-2026-64374

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-07-25T00:00:00Z

Links: CVE-2026-64374 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-04T14:45:03Z

Weaknesses

No weakness.