Linux 内核两个漏洞被公开

安世加

2026年10月23日 18:00
上海

去阅读

新闻

News Today

10月21日和22日，Trend Micro 旗下零日计划（ZDI）向 Linux 内核邮件列表提交了六份漏洞报告。其中两份落在 KSMBD——内核自带的 SMB 文件服务模块，每份 CVSS 都是 9.0，都能打到远程代码执行，其中一份不需要任何身份认证，只要 445 端口能连上就能打。

关键问题在于：这两份报告提交时，内核主干和 linux-next 里都没有修复代码，也没有 CVE 编号。按惯例这类报告走内核的私有安全邮件列表，等补丁就绪再公开。这一批直接发到了所有人都能读的 LKML 上。截至 10月23日，两个洞依然没有主干修复。

也就是说，攻击链路的细节已经躺在公开邮件存档里，而防守方手里没有可装的补丁。

先看不需要认证的那个，ZDI-CAN-33774。它是 KSMBD 协议分发环节的竞态：服务端在请求入队时就选定处理函数，但工作线程真正执行时才去读这个选择。攻击者在同一次 TCP 写入里先塞一批很短的 SMB1 报文、紧跟一个 SMB2 报文，连接就被切到 SMB2 处理路径上，而 SMB1 的缓冲区还没消费完，于是 SMB2 的代码读过小缓冲区的边界。有报道称越界读到的内核堆内容会随错误回复返回给攻击者。报告里还提到一条越界写路径，但需要先拿到共享目录的访问权限。

另一个 ZDI-CAN-33549 走的是 SMB Direct。SMB Direct 是把 SMB 流量跑在 RDMA 上的传输方式，主要在数据中心里用。客户端可以构造 RDMA 缓冲区描述符，让第一项长度超过声明的载荷长度，服务端的大小计数器发生整数下溢后回绕成一个极大值，后续的内存拷贝就越过了已分配的缓冲区。这条路径要求宿主机有 RDMA 接口（硬件或 rxe 软件驱动）、有可写共享，客户端还得协商 SMB Direct。SMB Direct 是独立的内核编译选项，默认关闭，门槛比第一个高得多。

另外四份报告风险低得多，也不会影响外部可达面：网络栈 skb\_zerocopy 的本地提权（7.8）、VMware 虚拟 GPU 驱动的越界写（8.8）、NVMe target 驱动的信息泄露（8.6），还有前一天进列表的 ConnMan 栈溢出。它们都需要本地已有权限，属于\"被打了之后往上爬\"那一类。

KSMBD 不是 Samba。它是三星主导另写的、和 Samba 兼容的另一套实现，Samba 联合创始人 Jeremy Allison 说过两边不共享代码。跑 Samba 的机器跟这两个洞没关系，大量企业内部的文件共享走的都是 Samba。

KSMBD 在上游内核配置里默认关闭，要真正对外提供文件服务还得额外装 ksmbd-tools 用户态守护进程。Red Hat 系（RHEL 及其衍生版）的默认内核根本没编进去。它出现最多的地方是家用 NAS、单板计算机和各类设备固件——图的是开销小。Armbian 给不少 ARM 板子编译的内核就打开了它。

所以真实的排查顺序是：先确定有没有，再谈怎么防。

查出来真在跑的，分三种情况处理。业务上根本不需要的，停服务、modprobe -r ksmbd 卸模块、再写进 blacklist 防止下次开机加载——这是最干净的做法。必须保留的，把 445 端口从公网彻底摘掉，源地址收成白名单，顺手把 guest 可访问的共享去掉；第一个洞的触发点就是 SMB1 与 SMB2 在同一连接上混用，能关掉 SMB1 协商就关掉。用得上 RDMA 的另说，但如果不是网络本身依赖 SMB Direct，就把它关掉，第二个洞的前置条件直接消失。

邮件列表里的回复比漏洞本身更有信息量。稳定内核维护者 Greg Kroah-Hartman 几分钟内连着回了好几封。关于 VMware 驱动那份，他写\"不知道出于什么原因你发到了公开列表，而且没带补丁，我们没什么能做的\"；十七秒后回 NVMe 那份：\"又是没补丁，还发到公开列表？请修正你们的提交流程。\"

这不是单纯的流程失误。报告署名的发现者是 TrendAI——Trend Micro 的 AI 漏洞扫描器。内核的安全文档今年 5 月由 Willy Tarreau 改写并合入 Linux 7.1，其中一条就是：AI 工具找到的漏洞应当视为已经公开，直接发给对应子系统的维护者，不必走私有列表。这个规则的由来是 Linus Torvalds 5 月 17 日的公开抱怨——重复的 AI 报告已经让私有安全列表\"几乎完全没法管理\"。他的理由是：一个 AI 工具能找出来，跑着同类工具的其他人也能找出来，保密换不来多少时间。

逻辑站得住，但执行起来是另一回事。同一份文档也要求提交者附上补丁或清晰的影响分析，而不是原始发现。这一批六份报告，补丁一个都没有。ZDI-CAN-33367 那份更说明问题：同一周前已经有另一位研究者报过同一个洞。本想减少重复私有报告的政策，结果是两个 9.0 分、影响服务端的洞在无补丁状态下摊在了公众面前。

再看披露节奏的错位。ZDI 自己的政策给厂商 120 天修复期；内核这边的规矩是私有列表不算披露渠道、公开已知漏洞的修复要立刻发、特例禁运一般不超过七天。两套时间表完全对不上，谁也没错，撞在一起就是现在这个局面。

稳定内核的修复从主干到 stable 分支、再到各发行版内核，通常还要几周。而这两个洞连 CVE 编号都还没有——内核项目只在修复进入 stable 树之后才分配。

没有 CVE 意味着扫描器匹配不到，资产平台的风险清单上看不见这两条。这不是它们无害的意思，是你们的工具在这个阶段对它天然失明。能用的补偿手段只剩网络侧：把 445 端口的暴露面收干净，在边界和东西向流量上盯 SMB1/SMB2 混发这类异常模式。

目前还没有在野利用的报告。但\"没有报告\"和\"没人试\"是两件事，这类长期维护者少、又老被 ZDI 盯上的子系统（KSMBD 2022 年 12 月、2026 年 8 月各出过一次 9 分级别的洞），历史记录说明不了安全。

要观察的就三件事：SMB Direct 那个补丁（SMB Direct 维护者 Stefan Metzmacher 据报已提交给下一开发周期，但没得到独立确认）什么时候进主干；ZDI-CAN-33774 的修复什么时候出现；以及各发行版什么时候回移植。发行版安全公告出来之前，能做的主要是减少暴露面，别指望用重载模块或者应用层绕过去——内核问题只能靠内核更新解决。

这一周本身就不太平，PHP2Shell 在前，KSMBD 在后，加上一串供应链和云平台事件。AI 让漏洞被找出来的速度超过了社区打补丁的速度，这个结构性缺口不会靠一两个流程调整补上。以后\"细节已公开、补丁未落地\"的窗口期，恐怕会越来越常见——真正该提前准备的是那段时间里能不能靠网络控制把风险压住，而不是等补丁。

来源：Phoronix

本公众号发布的文章均转载自互联网或经作者投稿授权的原创，文末已注明出处，其内容和图片版权归原网站或作者本人所有，并不代表安世加的观点，若有无意侵权或转载不当之处请联系我们处理！

安世加为出海企业提供SOC 2、ISO 27001、PCI DSS、TrustE认证咨询服务（点击图片可详细查看）