CVE-2026-74700— Linux kernel 安全漏洞
一分钟漏洞结论
影响对象
Linux Linux
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
Linux kernel是美国Linux基金会开源的一个操作系统内核。 Linux kernel 5.1版本存在安全漏洞，该漏洞源于销毁锁定的分类器时未正确获取rtnl_lock，导致竞争条件，可能导致释放后重用。
影响版本矩阵 12
| 厂商 | 产品 | 版本范围 | 状态 |
|---|---|---|---|
| Linux | Linux | 12db03b65c2b90752e4c37666977fd4a1b5f5824< 34e77d8e3570f9df3952496ddb402833695662fd |
affected |
12db03b65c2b90752e4c37666977fd4a1b5f5824< b648c8a56531aeabd1c14f6b5cf1891e269b3756 |
affected | ||
12db03b65c2b90752e4c37666977fd4a1b5f5824< d6222af7274f08e7a1848131dc30319993d8f377 |
affected | ||
12db03b65c2b90752e4c37666977fd4a1b5f5824< a81f9c44d87fb59d99fce72e29e02cab3a49a1c3 |
affected | ||
12db03b65c2b90752e4c37666977fd4a1b5f5824< a347304b2ca1a5377d5bd2d8a72e4b4f12afe648 |
affected | ||
5.1 |
affected | ||
< 5.1 |
unaffected | ||
6.6.152≤ 6.6.* |
unaffected | ||
| … +4 条更多 | |||
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-74700 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers
来源: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved:
net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers
Another challenge with unlocked filters.
There is a short window in tc_new_tfilter where a tcf_proto can be found
and briefly referenced by a totally unrelated, unlocked classifier's request
and cause a race.
Feng created a poc which created this race with two threads, one creating a
u32 filter and other a flower filter in the same chain/prio:
1. Both threads enter tc_new_tfilter, both find the chain empty, both
drop filter_chain_lock
2. u32 finishes tcf_proto_create("u32") first, calls
tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain
3. flower finishes tcf_proto_create("flower") later, calls
tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp
already there, takes a reference on it, destroys flower's own tp_new
and returns u32_tp to the caller.
Flower then hits the kind mismatch check (because it requested for kind
"flower" but tp->ops->kind is "u32") and goes through the errout path
which calls tcf_proto_put() on u32_tp. If the u32 thread has already
gone through its own errout (its change() call failed on the PoC's empty
options) and dropped its create and insert refs, flower's put is the
last one and drops u32_tp's refcnt to zero.
At this point tp->ops->destroy() runs in a context that never took
rtnl_lock. When that happens, it might cause a UAF like the following
(illustrated by the PoC):
[ +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393)
[ +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524
Call Trace:
u32_init (net/sched/cls_u32.c:393)
tc_new_tfilter (net/sched/cls_api.c:2378)
Allocated by task 526:
u32_init (net/sched/cls_u32.c:378)
tc_new_tfilter (net/sched/cls_api.c:2378)
Freed by task 522:
kfree
u32_destroy (net/sched/cls_u32.c:662)
tcf_proto_destroy (net/sched/cls_api.c:446)
tcf_proto_put (net/sched/cls_api.c:459)
tc_new_tfilter (net/sched/cls_api.c:2459)
Fix this by having tcf_proto_destroy() take rtnl_lock around
tp->ops->destroy() for locked classifiers whenever rtnl is not held.
To explain why I used a temp variable "not_lockless" I'd like to point to a
semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here
for future cleanup if deemed necessary):
The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are
redundant sources of truth for whether rtnl_lock is held. Among the nine
classifier destroy(..rtnl_held..) callbacks, only flower consults the
rtnl_held parameter which it propagates to tc_setup_cb_destroy()
and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic,
fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy()
(u32, bpf, mall) hardcode true always instead of forwarding the parameter.
A future cleanup should remove the rtnl_held parameter from the destroy callback
signature entirely and have callers rely solely on their knowledge whether
they are running in an unlocked context.
来源: CVE Program / CVE List V5
CVSS Information
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/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 5.1版本存在安全漏洞，该漏洞源于销毁锁定的分类器时未正确获取rtnl_lock，导致竞争条件，可能导致释放后重用。
来源: 中国国家信息安全漏洞库 CNNVD
CVSS Information
N/A
来源: 中国国家信息安全漏洞库 CNNVD
Vulnerability Type
N/A
来源: 中国国家信息安全漏洞库 CNNVD
受影响产品
二、漏洞 CVE-2026-74700 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-74700 的情报信息
请登录查看更多情报信息。
CVE-2026-74700 补丁与修复 (4)
同批安全公告 · Linux · 2026-08-22 · 共 149 条
| CVE-2026-74705 | 10.0 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74612 | 10.0 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74723 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74669 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74608 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74688 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74727 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74628 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74662 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74597 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74611 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74616 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74586 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74587 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74588 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74617 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74591 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74730 | 9.8 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74712 | 9.3 CRITICAL | Linux kernel 安全漏洞 |
| CVE-2026-74665 | 9.1 CRITICAL | Linux kernel 安全漏洞 |
显示前 20 条，共 149 条。 查看全部 → →
IV. Related Vulnerabilities
V. Comments for CVE-2026-74700
暂无评论