跳转至

科维斯 AI（Corvus AI）— TencentOS 内核漏洞研究智能体首秀

Ch04.480 科维斯 AI（Corvus AI）— TencentOS 内核漏洞研究智能体首秀

📊 Level ⭐⭐ | 7.8KB | entities/corvus-ai-tencentos-kernel-vulnerability-agent-2026.md

科维斯 AI（Corvus AI）— TencentOS 内核漏洞研究智能体首秀

摘要

科维斯 AI（Corvus AI）是 TencentOS 安全团队构建的 Linux 内核漏洞研究智能体，首次公开亮相便发现潜伏 18 年的 SCTP 协议栈 0day——CVE-2026-64564（SCTPhantom），自 Linux v2.6.25 起存在的 Use-After-Free，可本地提权与容器逃逸。从漏洞发现、稳定 root 提权、跨发行版迁移到补丁开发的全链路研究，从发现到修复合入主线仅 11 天。

核心要点

  • SCTPhantom（CVE-2026-64564）：SCTP 协议栈地址删除逻辑中的 Use-After-Free，相关代码 2008 年进入上游、随 v2.6.25 发布，潜伏超 18 年；修复仅 6 行代码。
  • 触发机制：单条消息中三个特定参数按特定顺序出现，前一个操作已释放的内核对象被后一个操作继续使用——单独执行每一步都符合协议规则。
  • 危害等级：普通用户权限 → 服务器 root；已验证的容器配置中可逃逸至宿主机 root（容器逃逸）。
  • 研究链路：首版自主编写的 PoC 即触发系统崩溃，经多轮根因分析与利用验证推进为稳定本地提权。
  • 跨发行版迁移：自动重定位并调整 29 处内核偏移与符号，约 3 小时将 TencentOS EXP 迁移到 Debian 默认内核并再次取得 root。
  • 影响面：已在 TencentOS Server、Debian 13、Ubuntu 24.04、RHEL 9.8 / Rocky 9.8 完成提权验证（RHEL 需预加载 SCTP 模块）。
  • 同期成果：在 Open vSwitch 模块独立发现另一本地提权漏洞 CVE-2026-64531（OVSwrap），确认与外部研究者"撞洞"。
  • 响应速度：7 月 12 日发现并构造 KASAN PoC，7 月 23 日补丁合入主线，8 月 4 日 CVE 分配当天 TencentOS 修复包即发布。

深度分析

SCTPhantom 根因：跨处理阶段的 UAF 为何难以定位

SCTP 与 TCP 的关键差异在于多宿主关联（multi-homing）：一个连接可同时使用多个网络地址，并允许在连接存续期间动态增删地址。漏洞正藏在地址删除（DEL-IP）逻辑中——补丁标题为 sctp: don't free the ASCONF's own transport in DEL-IP processing。单独执行时每一步操作都符合协议规范，但当三个特定参数以特定顺序出现在同一条 ASCONF 消息中，前一个操作释放的 transport 对象会被后续处理继续引用，形成经典的释放后使用。这类缺陷无法通过单函数检查发现：研究者必须同时理解协议状态机、参数执行顺序，以及同一内核对象跨越多个处理阶段的生命周期——这正是单一代码路径审计的天然盲区。

18 年未被发现：fuzzer 与人工审计的双重盲区

在此期间 Linux 内核经历数百个版本迭代、全球数千名开发者审阅，并被 Google syzkaller 等顶级 fuzzer 反复测试。coverage-guided fuzzer 擅长触发可独立达成的内存错误，但 SCTPhantom 需要多参数组合、特定顺序与协议状态前提同时成立，状态空间爆炸使命中概率极低；即便偶发 crash，fuzzer 也难以将其归因并判断安全含义。人工审计则依赖经验路径，这条"未被充分探索的执行路径"长期游离在常规注意力之外。此前的前沿模型实验也印证了差距：Mythos Preview 能发现内核内存越界写，却止步于宿主机拒绝服务，无法完成稳定利用链——发现、根因确认、利用开发与环境适配之间隔着完整的长链路工程，任何一个环节缺失都无法形成真实危害。

科维斯 AI 的工程化路径：Harness、多 Agent 与专家研判

科维斯 AI 并非单一 Agent 从头执行，而是围绕真实内核研究流程构建的体系：Agent Harness 框架将模型能力与专业安全工具、实验状态管理结合，保障长链路多轮次实验的连贯性与可验证性；多 Agent 协同扩大探索与验证能力；安全专家负责方法指导与关键判断，证据充分时推进、方向不成立时及时调整。围绕每次运行结果，Agent 持续参与根因分析——研判攻击者能否控制关键内核对象、能否获得所需地址信息、能否在真实防护配置下建立稳定利用链，并把已确认事实、失败路径与待验证问题沉淀为证据链，只有稳定复现且交叉验证的结论才进入利用与修复流程。跨发行版迁移进一步展示了系统性能力：自动分析两套内核在版本、编译选项、内存布局与防护配置上的差异，重定位 29 处偏移和符号，依据编译运行结果迭代修正，3 小时完成 TencentOS 到 Debian 的迁移。

从"等 CVE 公告"到"提前修复"：漏洞响应起点前移

传统操作系统漏洞响应从外部 CVE 开始：收到通告、判断影响版本、回补补丁、测试后发布。TencentOS 安全团队将起点前移——科维斯 AI 完成发现与危害验证后，产品侧同步启动影响研判、补丁回合、内核构建与回归验证，即使 CVE 编号尚未分配，也能依据真实利用证据提前判断风险。SCTPhantom 的响应时间线显示：发现到合入上游主线 11 天，CVE 分配当天修复包即已发布。团队坚持负责任披露原则，与上游社区协同修复、向监管报送，且在主要受影响产品完成修复前不公开完整利用代码。

实践启示

  1. 把漏洞研究当作可编排的长链路流程而非单次模型调用：Harness 框架 + 实验状态管理是多轮次、可验证内核研究的工程基础。
  2. 以"稳定复现 + 交叉验证"作为推进门槛：一次 crash 只证明问题可发生，须完成根因确认与可利用性研判后才进入利用阶段。
  3. 内核漏洞的影响评估必须覆盖跨发行版矩阵——内核版本、编译选项、模块加载状态（如 RHEL 需预加载 SCTP 模块）与防护配置都会改变危害结果。
  4. Agent 构建者应把研究延伸到"发现之后"：利用开发、跨环境迁移与补丁编写，并将失败路径和证据链沉淀为可复用的实验资产。
  5. 产品安全团队可将响应起点前移到 CVE 分配之前，利用内部发现驱动提前回补，把暴露窗口从"月"压缩到"天"。
  6. 评估安全 Agent 时警惕 benchmark 偏差：CyberGym 等评测多为给定漏洞描述后生成 PoC、且以用户态为主；无描述、无样例、无标准答案的内核 0day 发现才是更严苛的能力检验。

相关实体

→ 原文存档