2026 年 7 月 23 日,Linux 内核主线合入了一份只改动6 行代码的补丁。
它修复的漏洞,已经在 Linux 内核里存在了 18 年。
攻击者可以利用它,从一个普通用户权限提升到服务器 root 权限;在特定容器配置下,还能突破容器隔离,拿到宿主机的 root 权限。
这 18 年里,这段代码经历了数百个版本迭代、全球数千名开发者审阅、Google syzkaller 等顶级 fuzzer 的反复测试,也被无数安全研究者审计过——始终无人发现。
我们把它命名为 SCTPhantom(CVE-2026-64564),SCTP 协议栈中长期潜伏的幽灵。
发现它的,是 TencentOS 安全团队。
一、影响范围:TencentOS 同样受影响
SCTPhantom 源自 Linux 上游代码,所有基于该代码的发行版都可能受影响,TencentOS Server 也在其中。
我们完成了跨发行版的真实环境验证:
| | |
|---|
| TencentOS Server | | 默认配置可提权 |
| | |
| | |
| RHEL 9.8 / Rocky Linux 9.8 | | |
| | |
需要说明的是,这只是我们已完成验证的环境,不代表漏洞影响范围仅限于这些版本——实际影响面还取决于发行版采用的内核代码、补丁状态和 SCTP 功能配置。
二、这个漏洞为什么能藏 18 年
SCTPhantom 位于 Linux 内核的 SCTP 协议栈。
SCTP 常见于电信、专用通信和部分基础设施场景。和普通 TCP 不同,一个 SCTP 连接可以同时使用多个网络地址,也允许在连接存续期间动态增删地址。
问题就藏在地址删除的逻辑里。
单独执行时,每个操作都符合协议规则。但当三个特定参数按特定顺序出现在同一条消息中时,前一个操作已经释放的内核对象,会被后一个操作继续使用——由此形成内存释放后使用(Use-After-Free)漏洞。

这类问题几乎不可能靠单次函数检查发现。研究者必须同时理解协议状态、参数执行顺序,以及同一个内核对象跨越多个处理阶段的完整生命周期。
相关代码 2008 年进入 Linux 上游,随 v2.6.25 发布。此后 18 年,它躲过了所有传统手段。
三、它是怎么被发现的
发现它的,是 TencentOS 安全团队打造的内核漏洞研究智能体——科维斯 AI(Corvus AI)。
2026 年,AI 会写代码、会找漏洞已经不新鲜。但从"发现一处内存错误"到"构造出真实环境中稳定可用的利用链",中间是一条极长的工程链路——需要根因确认、利用开发、环境适配,任何一环断了都走不到终点。
所以我们没有把它做成"一个 Agent 从头跑到尾",而是把它组织成一套可持续运行的研究流程:
Agent Harness框架保障长链路、多轮次实验的连续性
多 Agent 协同扩大探索与交叉验证能力
安全专家研判负责方法指导与关键判断:证据充分时推进,方向不成立时及时调整
只有经过稳定复现和交叉验证的结论,才会进入后续的利用与修复流程。
两个结果值得说:
第一,它把一次crash 推成了稳定 root。科维斯 AI 自主编写 PoC,第一版就触发了系统崩溃——但一次 crash 只能证明"问题存在",不足以确认危害。经过多轮实验和复核,它最终在真实防护配置下建立了稳定的本地提权链路。
第二,3 小时完成跨发行版迁移。过去把一套内核利用迁移到另一个发行版,需要研究员逐项调试适配。我们把 TencentOS 上的利用代码交给科维斯 AI,要求迁移到 Debian 默认内核——它自动分析两个内核环境的差异,重新定位并调整了 29 处内核偏移和符号,全过程约 3 小时。
这一点对客户的意义是:我们能快速回答"这个漏洞在你的环境里到底有多危险",而不是给一个模糊的"可能受影响"。
同期,科维斯 AI 还在 Linux内核Open vSwitch模块中独立发现了另一个本地提权漏洞(CVE-2026-64531)并完成 root 验证——后续披露中确认有外部研究员早我们几天报告了同一问题。两个漏洞来自完全不同的子系统、成因也完全不同,科维斯 AI 都是从零出发完成的。这说明它不是一次偶然的运气。
四、这套能力,如何交付给客户
这是我们最想讲清楚的一点。
科维斯 AI 是 TencentOS 内部的安全研究能力,我们不会把它作为工具对外开源。内核漏洞利用能力本身具有双刃性,我们对此保持克制。
但客户不需要拥有这个工具,客户需要的是它带来的结果。我们把它变成了三件客户能直接感受到的事。
第一,漏洞响应的起点被往前挪了
传统的 OS 漏洞响应链路是这样的:等外部 CVE 公告 → 判断影响版本 → 回补补丁 → 测试 → 发布更新。起点不在自己手里,我们永远是被动的一方。
现在的链路是:我们自己发现 → 推动上游修复 → 同步启动产品影响研判、补丁回合、内核构建与回归验证。即使 CVE 编号还没分配,产品团队也能依据真实的利用证据提前判断风险、提前修复。
SCTPhantom 的时间线就是这条链路的实证:
| |
|---|
| 科维斯 AI 发现漏洞,当日构造 KASAN PoC,当日通过 Linux 上游私有渠道提交 |
| |
| 完成 TencentOS、Debian、Rocky / RHEL、Ubuntu 多发行版提权验证 |
| 7 月 23 日 | 修复补丁合入 Linux 内核主线 |
| |
| |
| CVE 编号正式分配(CVE-2026-64564) |
| 8 月 4 日 | TencentOS Server 同日发布内核修复安全公告及软件包 |
从发现到上游合入主线,11 天。CVE 分配当天,TencentOS 的修复包已经就位。
备注:对于研究中发现的安全漏洞,我们坚持负责任披露原则,与Linux内核社区协同推动修复,并已按规定向相关监管部门报送。在主要受影响产品完成修复前,我们不会公开完整利用代码和可复现攻击的细节。
第二,我们修的是整个 Linux,不只是 TencentOS
发现漏洞后我们做的第一件事,不是先修自己,而是当天就通过上游私有渠道提交给 Linux 内核社区,48 小时内拿到维护者 Ack,补丁最终合入主线并进入 stable 分支。
这意味着所有 Linux 发行版的用户都受益于这次修复——包括那些不用 TencentOS 的用户。基础软件的安全是共同体,这是我们对上游社区应尽的责任。
对于科维斯 AI 发现的所有漏洞,我们都坚持负责任披露:在主要受影响产品完成修复前,不公开完整利用代码和可复现的攻击细节。
第三,这套能力以服务的形式交付给客户
更早的风险通知:不必等公开 CVE,我们发现即启动客户侧影响研判明确的影响判定:不给“可能受影响”,给"你的版本、你的配置,是否可被利用"可跟踪的修复闭环:从漏洞公告、修复包、修复指引,到修复状态跟踪
工具留在内部,兜底的事我们来做。五、TencentOS客户关注
SCTPhantom 的修复已经发布。如果你正在使用 TencentOS Server,请: