来源 | 嵌入式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 的安全研究员。
——
各内核分支的修复版本：
fedeb4468987 | ||
74e8f3e7114f | ||
85aca407c560 | ||
d136b29bf91d | ||
9b2854f86f0b |
影响范围还是很大。
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 自己走完了。
完整的利用链是这样的：
UAF → pg_vec 回收 → direct-map 页地址泄露 → 4字节任意内核读 → IDT 绕过 KASLR → UAF 放置受控对象 → 伪造内核对象图 → commit_creds() → global root不依赖 ROP chain，不靠用户态 shellcode。从头到尾复用内核里已有的代码路径。
容器逃逸也验证了。默认 seccomp profile，不给 CAP_NET_ADMIN，八次尝试六次拿到宿主机 root——剩下两次是干净的 pointer-walk miss，没有引发内核 panic。
验证环境横跨了好几个发行版：自编译 7.2-rc2、OpenCloudOS 6.6.119、Debian 13（6.12.95）、Rocky/RHEL 9（5.14 厂商内核）、Ubuntu 24.04（6.8.0-134）。
——
还有个细节值得说。
科维斯AI 把 TencentOS 上的利用代码迁移到 Debian 默认内核，只用了大约 3 小时。AI 自动分析两个内核的差异，重新定位调整了 29 处内核偏移和符号。
以前这种事要安全研究员逐项调试，可能好几天。
而且科维斯AI 同期还在 Open vSwitch 模块里发现了另一个提权漏洞 CVE-2026-64531，也完成了 root 验证。后来确认有外部研究员早几天报告了同一个问题。
两个漏洞，不同子系统，不同成因。从零出发都找到了。
不是运气。
——
从发现到修复，11天
7月12日：科维斯AI 发现漏洞，当天构造 KASAN PoC，当天通过上游私有渠道提交。
7月14日：拿到 SCTP 子系统维护者 Ack。
7月15-23日：完成多发行版提权验证。
7月23日：修复补丁合入 Linux 内核主线。
8月3日：修复进入 Linux stable 分支。
8月4日：CVE 编号分配，TencentOS 同日发布修复包。
发现后做的第一件事不是先修自己，是当天就提交给 Linux 内核社区。所有 Linux 发行版的用户都受益——不管用不用 TencentOS。
基础软件的安全是共同体。
——
搞嵌入式软件这些年，内核代码翻了不少。
但我们更多是在"用"内核——编译、配置、调驱动，能用就行。像这样系统性地挖 0day、构造完整利用链，需要完全不同的能力层级。
科维斯AI 第一次公开亮相，就从一个藏了 18 年的老洞里挖出了本地提权 + 容器逃逸。
内核安全没有终点。以后还会有更多。
