Linux内核藏了18年的Bug,是如何被发现的?

来源 | 嵌入式Linux

2026年7月23日，Linux内核主线合入了一个补丁，就改了2行代码，修复的漏洞，在Linux内核里已经藏了18年。

2007年底，Linux 2.6.25合入了一个提交 42e30bf3463c，补全了一段 SCTP 协议地址重配置的代码。那时候我在学校刚接触51单片机，iPhone第一代才发布不到半年。

发现这个漏洞的，是TencentOS安全团队（腾讯朱雀实验室），和他们打造的AI——科维斯AI。

漏洞代号 SCTPhantom，CVE-2026-64564，CVSS v4.0 评分 8.5（High）。

——

这个漏洞，到底是怎么触发的？

SCTP 协议，搞网络的人应该知道。TCP 你知道，UDP 你也知道，SCTP 就是第三种传输层协议。平时用得少，但在电信网络、基站信令传输里很常见。

SCTP 有个特性叫多宿主——一个连接可以同时绑定多个 IP 地址，还能在连接过程中动态增删地址。这个动态增删的功能，就是 ASCONF（Address Configuration Change）。

问题就出在删除地址的逻辑里。

sctp_process_asconf() 函数在处理 ASCONF 消息时，会缓存一个 transport 指针放在 asconf->transport 里。然后按顺序处理消息里的操作参数。

当攻击者构造一条这样的 ASCONF 消息：

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

一步步看发生了什么：

1. 数据包的源地址是 S，但 Address Parameter 指向的地址是 L（L ≠ S）

2. 第一个操作 DEL-IP L：内核检查源地址 S，发现不是删自己，通过检查 → 调用 sctp_assoc_rm_peer() 释放了 asconf->transport 指向的对象（RCU延迟释放）

3. 第二个操作 DEL-IP 0.0.0.0（通配符删除）：此时 asconf->transport 已经是悬空指针，但内核继续用这个指针去调 sctp_assoc_set_primary() 和 sctp_assoc_del_nonprimary_peers()

结果就是：一个已经被释放的 transport 对象，被当成还在使用的路径，继续被引用。

经典的 Use-After-Free。

单看每个操作，DEL-IP L 的 D8 检查（源地址不能删自己）是正常的，通配符 DEL-IP 的处理也是正常的。但把它们按这个顺序串起来，前脚释放的对象后脚就被继续用。

代码 review 几乎不可能发现。fuzzer 也很难触发——你得同时理解协议状态、参数执行顺序、内核对象的完整生命周期。Google 的 syzkaller 够强了吧？18年也没撞上这条路径。

——

修复长什么样？

上游补丁提交 9b2854f86f0b，标题：

sctp: don't free the ASCONF's own transport in DEL-IP processing

修改文件：net/sctp/sm_make_chunk.c

改的就是两行：

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9b2854f86f0b56e9027d68e7a3fc909d1a9b566f

在 sctp_assoc_rm_peer() 释放 transport 之前，先判断要删的 peer 是不是 ASCONF 自己缓存的那个 transport。如果是，拒绝删除。

就这一行判断，让通配符分支再也不会拿到一个已经释放的 transport。

代码的作者是 TencentOS 的安全研究员。

——

各内核分支的修复版本：

影响范围还是很大。

TencentOS Server、Debian 13、Ubuntu 24.04 默认配置就能提权。RHEL 9.8、Rocky Linux 9.8 加载了 SCTP 模块也会中招。Docker 环境里还能容器逃逸——从容器内拿到宿主机 root。

——

从一次崩溃到稳定 root，AI 自己走完了全链路

科维斯AI 第一版 PoC 就触发了内核崩溃。

但 crash 只能证明"这地方有问题"，不能证明"攻击者可以利用它拿 root"。

从 crash 到 stable root，中间是一条很长的工程链路。科维斯AI 自己走完了。

完整的利用链是这样的：