10 月 21 日到 26 日这五天，Linux 内核圈出现了一种罕见的"披露真空"：趋势科技旗下 ZDI 把 6 份带完整 PoC 源码的漏洞报告直接发上了公开邮件列表，其中两个 KSMBD 漏洞被评到 CVSS 9.0、不用登录就能远程触发，而补丁还没进主线；10 月 26 日，360 漏洞研究院又发通告，一个潜伏六年半的本地提权漏洞 CVE-2026-98260 已被复现，Ubuntu 和三星 Galaxy S26 Ultra 都在已验证受影响的名单里。这几件事连起来看，指向的不是"漏洞又多了一个"，而是一个更扎心的新问题：你的漏洞扫描器，可能压根看不见它们。哔哩哔哩知乎
补丁没合并，PoC 先挂上了公开列表
10 月 21 日和 22 日，趋势科技零日计划（ZDI）把 6 份漏洞报告发到了公开的内核邮件列表（LKML、linux-cifs、netdev、dri-devel），其中几份带着 KASAN 调用栈、代码路径和完整 PoC 源码，却没有一份附带补丁。稳定内核维护者 Greg Kroah-Hartman 在同几分钟内回信，直接质问：又一次，没有补丁，还发到了公开列表？并要求 ZDI 修正提交方式。哔哩哔哩哔哩哔哩
评分 9.0 的两个洞都落在 KSMBD——内核内置的 SMB3 服务器，是 NAS 和局域网文件共享常用的那一种：
ZDI-CAN-33774：协议分发表竞态。攻击者在同一个 TCP 写请求里塞一串短 SMB1 包、再跟一个 SMB2 包，工作线程就会用 SMB2 处理器去处理还没消费的 SMB1 缓冲，发生越界读。不需要登录，据 TuxCare 复现，每次泄漏约 28 字节内核堆内存，还可能直接把内核打崩。修复 commit（68f410faedaf）已经放在 ksmbd 维护者树里，但还没进主线。
ZDI-CAN-33549：SMB Direct 路径的整数下溢。客户端给出首条目长度大于声明载荷的 RDMA 缓冲描述符，长度计数器回绕，后续拷贝越过缓冲区，堆溢出最多约 8 KB。触发条件苛刻一些：要开启 SMB Direct、有 RDMA 接口、有可写共享，还要客户端协商 SMB Direct。据报道，修复已提交到面向 Linux 7.5 的分支。
最反直觉的一点：没有 CVE，不等于没有漏洞
内核项目的惯例是补丁进入稳定分支之后才分配 CVE 编号。于是这两个 9.0 分的洞目前处于"零 CVE"状态——按 CVE 编号匹配的扫描器，一条都扫不出来。时间线也更尴尬：据 pwn.watch 的排期，ZDI 的正式公告要到 2027 年 2 月才发。翻译一下：PoC 源码今天就躺在公开邮件列表上，官方通告却排在四个月之后，中间的窗口期只能靠人工自查。哔哩哔哩
为什么会"提前公开"？因为是 AI 找到的
这不是 ZDI 心血来潮，而是一套新规则的产物。内核安全文档在 2026 年 5 月经过更新（据 Phoronix 报道，Linus Torvalds 参与了这次更新），认定"由 AI 工具发现的漏洞，按定义已经公开"，应直接发送给子系统开发者列表。而 ZDI 这次把发现功劳，记在了 TrendAI——趋势科技的 AI 漏洞扫描器——头上。哔哩哔哩
AI 的发现速度早就淹过了审核管道。Linus 在 7.1-rc4 的发布邮件里吐槽，AI 报告的持续泛滥基本让安全列表几乎完全无法管理，不同的人用同样的工具发现同样的问题；安全列表一天要收到 5 到 10 份 AI bug 报告，网络子系统维护者 Jakub Kicinski 在 7.2 周期里更是直接删掉了近 4000 行 AppleTalk 代码——理由就是一波没人审查的 AI 生成补丁涌进来，同一周期被清退的还有 ARCnet、ISDN、AX.25 这些老驱动。知乎
至于 ksmbd 这块代码，本身就是 AI 的老朋友：2026 年 5 月，OpenAI 的 o3 模型对它做过安全审计，从中翻出了一个远程零日漏洞，编号 CVE-2025-37899。同一片代码，半年里被 AI 连点两次名，披露节奏也只好跟着发现速度一起改。知乎知乎
今天的续集：潜伏六年半的 UAF，复现者也是 AI
10 月 26 日，360 漏洞研究院发布通告：CVE-2026-98260（CVSS 7.8）是 POSIX CPU 计时器与 exec() 执行路径中的释放后使用缺陷，漏洞自 Linux 内核 5.7 引入，从出现到修复历时约 6 年 6 个月。官方修复提交的标题是 “exec: Cleanup POSIX timers right after de_thread()”，已验证的受影响对象包括 Ubuntu 发行版和三星 Galaxy S26 Ultra，而复现它的同样是 AI——360 图龙锋漏洞挖掘智能体。知乎
要强调的是，这是一个本地提权漏洞：利用前置条件是攻击者已经能在目标系统上以低权限用户身份执行代码。所以它的真实威胁面不是你的个人台式机，而是多用户服务器、共享开发机、跳板机这类"人人都有账号"的环境——只要系统上存在任何一个不可信的本地账号，门就是开着的。
自查清单：谁该紧张，该做什么
NAS / OpenWrt 玩家：先跑一句 `lsmod | grep ksmbd`，看看内核态 SMB 有没有在用（刷了 OpenWrt、装了 luci-app-ksmbd 的尤其注意）。如果加载了，确认 445 端口没有暴露公网。
服务器管理员：没用 RDMA 存储就关掉 SMB Direct；盯两个信号——ksmbd 维护者树里的修复 commit 何时进主线、7.4/7.5 的 stable 何时发版。
Android 用户：S26 Ultra 已出现在已验证受影响名单里，本地提权的现实风险主要来自恶意 App 链式利用，坐等 OEM 安全补丁并尽快更新即可。
单机桌面用户：CVE-2026-98260 这类提权漏洞需要一个"已经能登录的敌人"，独享机器的优先级可以放低，跟着发行版的更新节奏走。
所有 Linux 运维：下次看到通报里没有 CVE 编号的漏洞，别急着划走——扫描器按编号匹配，编号要等补丁进 stable 才分配，没有编号的那条，恰恰可能最危险。
最后
内核社区的老传统是"补丁先行，然后披露"，因为公开披露的前提是维护者接得住。但 AI 改写了前提：漏洞出现在模型输出里的那一刻，它事实上就已经公开了——发不发邮件列表只是形式。这个 10 月，LKML 成了公开的漏洞公告板，PoC 比补丁先到，扫描器因为没编号集体失明，用户只能靠一句 lsmod 自查。安全流程跟不上发现速度这件事，过去是运维新闻里的一句话，现在是每台服务器都得自己面对的窗口期。
