F12笔记10 月 22 日，六个还没修的 Linux 内核漏洞，被安全研究机构 ZDI（趋势科技旗下）直接发到了公开的 Linux 内核邮件列表。
其中两个的 CVSS 评分是 9.0，都可能打到远程代码执行。
内核维护者 Greg Kroah-Hartman 在回复里只写了一句：And again, no patch...（又是这样，补丁呢？）
一、先搞清性质：这不是"漏洞很严重"，是"流程出事了"
Linux 内核处理未修复漏洞的正常流程是：
- 报告者先发到私密邮件列表（[email protected]），只给维护者看；
- 维护者做出补丁；
- 补丁发布后，才公开细节。
这次 ZDI 跳过了第 1 步，把报告直接贴进了 LKML（公开邮件列表）。
所以问题的核心不是"漏洞有多严重"，而是：一份本来应该只有维护者看到的利用细节，现在所有人都能看到了，而没有补丁。
二、六个漏洞，逐个看
这六个不是"所有 Linux 用户都中招"的意思，每个都有具体触发条件：
① ZDI-CAN-33549：SMB Direct（CVSS 9.0）
SMB Direct 是走 RDMA 的 SMB 传输方式。这个漏洞是整数下溢导致的远程代码执行。
谁能打到：机器上跑着 SMB 服务端（走 RDMA），并且对外可达。家庭用户、普通 VPS 基本不碰 —— 你要有 RDMA 网卡（InfiniBand 或 RoCE），或者跑着 Hyper-V / Samba 的 RDMA 模式。
② ZDI-CAN-33774：KSMBD（CVSS 9.0）
KSMBD 是内核态的 SMB 服务器（替代用户态的 Samba）。这个漏洞是协议分发的竞争条件，同样能打到远程代码执行。
谁能打到：用 ksmbd 把 Linux 当 SMB 文件服务器用的机器 —— 比如软路由、NAS、Windows 共享盘。装了就查：
lsmod | grep ksmbd如果没有输出，说明你没在用，这条和你无关。
③ ZDI-CAN-33367：skb_zerocopy（本地提权）
网络栈里 skb_zerocopy 的问题，属于本地权限提升。
谁能打到：已经能在机器上跑代码的本地用户（包括被攻破的容器进程）。远程打不了，所以优先级比前两个低一档。
④ ZDI-CAN-34068：VMware 图形驱动 VMWGFX（本地提权）
越界写导致本地提权。
谁能打到：在 VMware 虚拟机里跑 Linux 桌面的机器。云服务器、物理机、KVM 虚拟机都不沾。
lsmod | grep vmwgfx⑤ ZDI-CAN-34076：NVMe Target（信息泄露）
未初始化资源导致内存信息泄露。
谁能打到：把机器当 NVMe-oF 存储目标端用的（nvmet）。普通机器上就是块硬盘，用不到这个模块。
⑥ ZDI-CAN-32005：网络查询处理（本地提权）
栈缓冲区溢出，同样是本地提权。
三、"误公开"到底有多麻烦
麻烦在三个点叠加：
- 细节公开了 —— 报告里通常包含触发方式、崩溃位置、甚至 PoC 思路；
- 补丁还没有 —— Greg KH 的原话是 "no patch"；
- ZDI-CAN 编号不是 CVE —— 意味着没有正式的 CVE 条目、没有 CVSS 官方评分表、也没有可追踪的发行版安全公告。
第三点最容易被误解：网上很多文章把 ZDI-CAN-33549 当成"漏洞编号"，其实它是 ZDI 的内部案件号。发行版的安全公告里不会出现这个号 —— 你没法用它在 Debian / Ubuntu 的安全追踪里查补丁状态。
所以对运维来说，现在的处境是：知道有个洞，但不知道自己的发行版修没修。
四、你该做什么
第一步：查自己有没有暴露面
把下面这条跑一遍，看有没有输出：
lsmod | grep -E 'ksmbd|vmwgfx|nvmet|smbdirect'- 没有任何输出 → 六个里有四个和你无关（SMB Direct、KSMBD、VMWGFX、NVMe Target 都要对应模块）；
- 有输出 → 把对应服务先关掉，等补丁。比如
systemctl stop ksmbd、systemctl disable ksmbd。
第二步：把内核升到最新（哪怕补丁还没进）
这六个漏洞的修复都会进内核稳定版。先把内核包升上去，补丁到了直接生效，不用再等一轮。
# Debian / Ubuntu
apt update && apt install --only-upgrade linux-image-amd64
reboot注意最后那行 reboot。升内核包和换内核是两件事 —— 包升级了但没重启，跑的还是旧内核。
第三步：这两个本地提权，优先级往后放
skb_zerocopy 和网络查询那两条都是本地提权，前提是攻击者已经能在你机器上执行代码。如果你连远程面都没暴露，它们排不上号。
五、顺手看了眼自己的服务器
我拿这台 Debian 13 的机器跑了一遍：
uname -r
6.12.111+deb13-amd64
apt-cache policy linux-image-amd64
Installed: 6.12.113-1
Candidate: 6.12.113-1装的是 6.12.113，跑的是 6.12.111 —— 就是上面说的"升级了没重启"。
模块查下来：
lsmod | grep -E 'ksmbd|vmwgfx|nvmet|smbdirect'
（无输出）四个模块一个都没加载，所以这六个里，只有两个本地提权理论上和我有关，而且还需要先有人能在这台机器上执行代码。
结论：重启一下就行，不用慌。
六、为什么这类新闻以后会越来越多
一年前，一份内核漏洞报告从提交到公开，中间要经过报告者、维护者、发行版好几道手。
现在 AI 辅助审计让"找洞"的成本降了一个数量级 —— 提交量上去了，流程就容易被挤爆。ZDI 这次的失误，很可能只是第一个被注意到的。
对你我这种普通运维来说，应对方式反而简单：盯住"我有没有暴露面"，而不是盯住每一个 CVE 号。
七、官方网址都在这里
这篇不是二手转述，原始出处全都能点开核对：
- Phoronix 首发报道（10 月 22 日）：phoronix.com/news/LKML-New-Trend-Vulnerabilities
- Greg KH 的原邮件（openwall 镜像，国内可直连，不用过机器人验证）：lists.openwall.net/linux-kernel/2026/10/22/313
- 同一封邮件的 LKML 原页：lkml.org/lkml/2026/10/22/319（这个站挂了 Anubis 反爬，需要浏览器过验证）
- ZDI 已发布公告列表：zerodayinitiative.com/advisories/published/
注意最后一条：ZDI 的公告列表里查不到 ZDI-CAN-33549 / ZDI-CAN-33774 这些编号。原因就是上面说的 —— ZDI-CAN- 是 ZDI 的内部案件号，只有走完流程、厂商出了补丁，才会转成 ZDI-26-xxx 这种正式公告编号。现在它们是"半公开"状态：邮件列表里能看到，正式公告页里没有。
事实与编号来自 Phoronix 10 月 22 日报道、LKML 公开邮件列表、ZDI 与各家媒体；本机数据为本文写作时的实测。
10 月 22 日报道、LKML 公开邮件列表、ZDI 与各家媒体；本机数据为本文写作时的实测。
