编者按：AI 正在加速高危内核漏洞的发现，修复工作的压力也随之陡增。传统的热补丁技术虽然解决了重启的痛点，但将上游补丁改造成可加载的热补丁，仍然是一件极其依赖人工的苦差事。在 2026 全国大学生计算机系统能力大赛技术培训会上，龙蜥社区系统运维 SIG 成员高向阳分享了他们如何利用 AI Agent 将这一周期从天级压缩到分钟级。以下为分享实录。
背景：当 AI 成为漏洞“翻跟斗”
如果你最近关注 Linux 内核安全动态，一个趋势已经非常明显：在 AI 的助攻下，高危内核 CVE 正在以周为周期密集涌现。
看看最近一连串的漏洞吧。研究者先提出攻击假设，AI 就能迅速枚举出完整的攻击路径。其中一个漏洞，公开后一小时内就被 AI 发现，影响范围横跨 Linux 4.14 到 6.19，整整七年。攻击方式更是简单粗暴——一个七百多字节的 Python 程序，通过攻击 Page Cache 就能一键本地提权到 root。
更棘手的是，漏洞发现的速度越来越快。有时候，一个漏洞公开后不到一周，下一个就来了。很多企业还在修复第一个，第二、第三个又已兵临城下。在多租户云环境中，这类本地提权漏洞一旦被利用，主机逃逸几乎就是一瞬间的事，大量线上 Linux 服务器亟待修复。
传统修复与内核热补丁：重启 vs. 换引擎
传统方式：升级内核，重启是绕不开的坎
传统的修复流程很清晰：拿补丁、重编译、再部署、重启生效。这个流程中，最大的痛点是重启服务器，也就是业务必须中断。
内核热补丁：飞行中换引擎
内核热补丁（Live Patching）最大的价值就在于此——无需重启。这就像在一架飞行中的飞机上更换引擎零件，业务完全无感。在 CVE 修复场景下，它的两大核心优势显而易见：构建、测试、部署的链条更快，以及对业务的影响极小。
技术框架：热补丁是怎么工作的？
内核热补丁的技术框架可以分为三层。第一层是 kpatch 工具链。它是构建和管理热补丁的利器，核心组件 Kpatch-build 的流程是这样的：先对原始内核源代码做一次全量编译，打上 Patch 后再做一次增量编译，然后对比两次编译出的 .o 文件，找出哪些函数发生了变化，最后把这些修改过的函数链接起来，生成最终的 .ko 内核模块。加载这个模块后，就能完成对特定函数的修复。
第二层是 Livepatch 子系统。Kpatch 在内核中的运行靠它支撑，它从内核 4.0 开始就已经是原生功能了。第三层是 Ftrace 插桩机制。Ftrace 在编译时为每个函数的入口预留了一条空指令，运行时可以动态替换为跳转指令，跳转到新函数的入口，实现函数重定向。简单说，就是在内核运行时，把特定函数的入口地址替换掉，让它跳转到修复后的新函数。
从上游补丁到可加载热补丁：一道鸿沟
上游的修复补丁并不能直接拿过来就用。Kpatch 工具链对补丁有相当多的限制：
| 约束项 | 说明 |
| 不能修改 init 函数 | 这些函数在引导阶段后，对应内存段已被释放，无法替换。 |
| 不能修改静态分配的数据 | 比如向全局数组新增元素或变量。 |
| 不能修改缺少 fentry 的函数 | 比如 lib 下很多静态链接的库函数，编译时没预留 fentry 入口。 |
| 不能改变导出符号的签名 | 这会破坏内核 ABI，影响其他模块调用。 |
| 不能更改现有数据结构 | 比如向结构体增加字段，无法在运行时替换所有实例并避免风险。 |
| 不能删除对静态局部变量的引用 | / |
正是这些约束，导致上游补丁必须经过人工改写和适配。而这一过程目前完全依赖手工，一个 CVE 补丁可能耗时数小时甚至数天。加上线上存在大量不同版本的内核，每次迁移还要根据基线差异额外调整。当 CVE 密集出现时，人工改写就成了最大的瓶颈。
实战：copy_file 漏洞的热补丁改写
拿最近公开的 copy_file 漏洞来说，我们可以看看一个上游补丁是如何被改写成热补丁的。这个漏洞源于加密模块中的一个零拷贝优化，导致可以越权篡改只读的 Page Cache。攻击者篡改 password 或 setuid 这类文件，用一段简单的 POC 程序就能从任意用户提权到 root，影响时间跨度很长。上游的修复方案是：回退 2017 年引入的零拷贝优化，改成拷贝后再写入。
上游修复有多复杂？
以某个主流发行版的 5.10 内核开发分支为例，修复这个 CVE 需要回合多个前置依赖 commit，最终提交包含十个 commit、十一个文件的修改，新增和删除的代码行数相当多。
直接构建会遇到哪些问题？
如果直接拿上游补丁来构建热补丁，会遇到四类典型问题：
- 问题一：修改了 Kernel Config。补丁里包含内核配置文件的修改。Config 是控制编译过程的，修改它不仅无意义，还会导致大量代码的条件编译发生变化，产生大量不被允许的修改。
- 问题二：导出函数删除了参数。有两个导出函数删除了末尾参数。这在普通情况下没问题，但导出函数的签名被修改了，这会破坏 ABI。
- 问题三：删除了结构体成员。两个结构体被删除了部分成员。这是静态数据结构的修改，不支持在运行时替换所有实例。
- 问题四：新增函数声明了导出符号。新增函数本身没问题，但上游补丁增加了导出符号的声明。内核运行时的符号表是固定的，无法扩容或注册新符号。
改写策略
对应这些问题的改写策略其实很直接：Config 修改直接去掉，不需要改配置；删除参数就保留参数，内部逻辑不再用它；删除结构体成员就保留，不再使用它；新增函数的导出声明去掉，让函数只在模块内部使用，完全不影响修复目的。改写完成后，文件从十一个减少到七个，构建成功，加载后也能正常完成 CVE 修复。
2026 大学生 OS 赛题要求
2026 全国大学生计算机系统能力大赛中，龙蜥“内核 CVE 热补丁自动生成智能体”这个赛题，就是要参赛者开发一个智能体，能够在不改变原修复语义的前提下，自动完成补丁的改写和构建，实现高效、安全的内核漏洞修复。高向阳也给出了具体的评估标准。
更多赛题详情可点击右侧链接查看：龙蜥邀您参加 2026 全国大学生计算机系统能力大赛
结语
AI 不仅加速了漏洞的发现，也正在成为加速修复的关键驱动力。在 2026 年的这场大赛中，我们希望能推动内核热补丁技术从“人工驱动”向“智能体驱动”的范式跃迁，将热补丁的生成周期从天级压缩到分钟级。期待各参赛队伍能深入系统底层，提出既有前瞻性又落地可行的创新方案。
视频回放链接：https://openanolis.cn/video/1633914108607529089
相关阅读文章：
从“救火”到“预见”：汽车行业操作系统智能运维解决方案
开源！智能运维助手上线，SysOM MCP 为 AI Agent 打开系统诊断之门
Anolis OS 深度集成运维利器，阿里云操作系统控制台上线
