CVE-2026-64374

Status: UPDATED  |  Advisory ID: CVE-2026-64374

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References