CVE-2026-64374— Linux kernel 安全漏洞
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
Linux kernel是美国Linux基金会开源的一款操作系统内核。 Linux kernel 4.1版本存在安全漏洞，该漏洞源于RT_PUSH_IPI逻辑默认开启，在处理IPI时与软中断交互不当，可能导致CPU活锁。
可能的 ATT&CK 技术 1 AI
T1496 · Resource Hijacking影响版本矩阵 18
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| Linux | Linux | b6366f048e0caff28af5335b7af2031266e1b06b< b99f04ae3d200d2f8844aa29145bd18eccbeecde |
affected |
b6366f048e0caff28af5335b7af2031266e1b06b< d8312a56d9a162e3ec76476aa487e7d20bc602e9 |
affected | ||
b6366f048e0caff28af5335b7af2031266e1b06b< 44aae426dbfd51286f7eb601cfa14bc32164812a |
affected | ||
b6366f048e0caff28af5335b7af2031266e1b06b< 860aaff72c8446fed5e576249e19952883a18885 |
affected | ||
b6366f048e0caff28af5335b7af2031266e1b06b< 89237c8fc15d8016a194076e648ccb57d75e65ae |
affected | ||
b6366f048e0caff28af5335b7af2031266e1b06b< 4bd0da48fbc1dbef6774175129107fbbdd353e26 |
affected | ||
b6366f048e0caff28af5335b7af2031266e1b06b< a18f80bf5359238c4f067d691b96af00286fdd89 |
affected | ||
b6366f048e0caff28af5335b7af2031266e1b06b< dd29c017aed628076e915fe4cdfb5392fd4c5cab |
affected | ||
| … +10 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-64374 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT
来源: CVE Program / CVE List V5
Vulnerability 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.
来源: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
来源: CVE Program / CVE List V5
Vulnerability Type
N/A
来源: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Description
Linux kernel是美国Linux基金会开源的一款操作系统内核。 Linux kernel 4.1版本存在安全漏洞，该漏洞源于RT_PUSH_IPI逻辑默认开启，在处理IPI时与软中断交互不当，可能导致CPU活锁。
来源: 中国国家信息安全漏洞库 CNNVD
CVSS Information
N/A
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Type
N/A
来源: 中国国家信息安全漏洞库 CNNVD
受影响产品
二、漏洞 CVE-2026-64374 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-64374 的情报信息
请登录查看更多情报信息。
CVE-2026-64374 补丁与修复 (7)
同批安全公告 · Linux · 2026-07-25 · 共 274 条
| CVE-2026-64355 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64459 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64303 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64439 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64410 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64399 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64397 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64391 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64387 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64386 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64385 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64383 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64384 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64268 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64523 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64269 | 9.1 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64257 | 9.1 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64319 | 9.1 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64320 | 9.1 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-64393 | 9.1 CRITICAL | Linux kernel 安全漏洞 |
显示前 20 条，共 274 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2026-64374
暂无评论