CVE-2026-64374

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT<br /> <br /> RT migration is done aggressively. When a CPU schedules out a high<br /> priority RT task for a lower priority task, it will look to see if there&amp;#39;s<br /> any RT tasks that are waiting to run on another CPU that is of higher<br /> priority than the task this CPU is about to run. If it finds one, it will<br /> pull that task over to the CPU and allow it to run there instead.<br /> <br /> Normally, this pulling is done by looking at the RT overloaded mask (rto)<br /> which contains all the CPUs in the scheduler domain with RT tasks that are<br /> waiting to run due to a higher priority RT task currently running on their<br /> CPU. The CPU that is about to schedule a lower priority task will grab the<br /> rq lock of the overloaded CPU and move the RT task from that CPU&amp;#39;s runqueue<br /> to the local one and schedule the higher priority RT task.<br /> <br /> This caused issues when a lot of CPUs would schedule a lower priority task<br /> at the same time. They would all try to grab the same runqueue lock of<br /> the CPU with the overloaded RT tasks. Only the first CPU that got in will<br /> get that task. All the others would wait until they got the runqueue lock<br /> and see there&amp;#39;s nothing to pull and do nothing. On systems with lots of<br /> CPUs, this caused a large latency (up to 500us) which is beyond what<br /> PREEMPT_RT is to allow.<br /> <br /> The solution to that was to create an RT_PUSH_IPI logic. When any CPU<br /> wanted to pull a task, instead of grabbing the runqueue lock of the<br /> overloaded CPU, it would start by sending an IPI to the overloaded CPU,<br /> and that IPI handler would have the CPU with the waiting RT task do a push<br /> instead. Then that handler would send an IPI to the next CPU with<br /> overloaded RT tasks, and so on. Note, after the first CPU starts this<br /> process, if another CPU wanted to do a pull, it would see that the process<br /> has already begun and would only increment a counter to have the IPIs<br /> continue again.<br /> <br /> The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause<br /> a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded<br /> context on PREEMPT_RT but they can run in an interrupt context in non-RT.<br /> <br /> If an IPI lands on a CPU that has just woken up multiple RT tasks and the<br /> current CPU is running a non RT or a low priority RT task, instead of<br /> doing a push, it would simply do a schedule on that CPU. But if a softirq<br /> was also executing on this CPU, the schedule would need to wait until the<br /> softirq finished. Until then, the CPU would still be considered overloaded<br /> as there are RT tasks still waiting to run on it.<br /> <br /> A live lock occurred on a workload that was doing heavy networking traffic<br /> on a large machine where the softirqs would run 500us out of 750us. And it<br /> would also be waking up RT tasks, causing the RT pull logic to be<br /> constantly executed.<br /> <br /> When a softirq triggered on a CPU with RT tasks queued but not running<br /> yet, and the other CPUs would see this CPU as being overloaded, they would<br /> send an IPI over to it. The CPU would notice that the waiting RT tasks are<br /> of higher priority than the currently running task and simply schedule<br /> that CPU instead. But because the softirq was executing, before it could<br /> schedule, it would receive another IPI to do the same. The amount of IPIs<br /> would slow down the currently running softirq so much that before it could<br /> return back to task context, it would execute another softirq never<br /> allowing the CPU to schedule. This live locked that CPU.<br /> <br /> As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if<br /> PREEMPT_RT is not enabled.