Detections
Analytics

Echo: linux: security update to 6.1.180-1

high Tenable Self-Hosted Container Security Plugin ID 458595

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

 - 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. (CVE-2026-64374)

Solution

Update the linux library and its related packages to version 6.1.180-1 or later.

See Also

https://advisory.echohq.com/cve/CVE-2026-64374

Plugin Details

Severity: High

ID: 458595

Version: Revision 1.1

Type: Local

Published: 10/2/2026

Updated: 10/2/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.72

CVSS v2

Risk Factor: High

Base Score: 7.8

Temporal Score: 5.8

Vector: CVSS2#AV:N/AC:L/Au:N/C:N/I:N/A:C

CVSS Score Source: CVE-2026-64374

CVSS v3

Risk Factor: High

Base Score: 7.5

Temporal Score: 6.5

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Patch Publication Date: 7/26/2026

Vulnerability Publication Date: 7/23/2026

Reference Information

CVE: CVE-2026-64374