编者按：在 AI 技术的推波助澜下，高危内核 CVE 以周级频率爆发，系统修复面临前所未有的压力。尽管内核热补丁技术克服了传统修复需重启服务器的弊端，实现了业务零中断，但从上游原始 Patch 到可加载热补丁的转化过程，仍依赖大量繁琐的人工改写。
针对这一痛点，龙蜥社区系统运维 SIG 成员高向阳在 2026 全国大学生计算机系统能力大赛技术培训会上，详细剖析了如何利用 AI Agent 实现热补丁的自动化生成，成功将补丁制作周期从“天级别”压缩至“分钟级别”，有力证明了 AI Agent 已成为驱动内核安全修复效率变革的新引擎。以下为本次分享内容：
背景：AI辅助下的内核CVE周级涌现
如果你最近关注 Linux 内核安全动态，一定已经注意到一个令人警惕的趋势——在 AI 的辅助下，高危内核 CVE 正以周级的速度密集涌现。
以近期引发广泛关注的几个漏洞为例：安全研究员首先提出攻击假设，再由 AI 枚举出完整的攻击路径。其中某个漏洞在公开后一小时内就被 AI 发现，影响范围覆盖从 Linux 4.14 到 6.19、长达七年的所有内核版本。攻击方式也极为简单粗暴——仅需一个七百多字节的 Python 程序，即可通过攻击 Page Cache 实现一键本地提权至 root。
更令人担忧的是，这些漏洞的发现和公开速度越来越快。从某个漏洞公开到下一个漏洞被发现，间隔甚至不到一周。很多企业在第一个漏洞尚未修复完成时，第二个、第三个漏洞已经接踵而至，修复压力巨大。
而在多租户云环境中，这些可被用于本地提权的漏洞一旦利用成功，主机逃逸将变得易如反掌，线上大量的 Linux 服务器都需要尽快修复。
传统修复 vs 内核热补丁
传统方式：升级内核，必须重启
传统的内核修复流程通常是：获取最新的修复补丁 → 重新构建内核镜像 → 重新部署替换 → 重启服务器生效。
整个流程对业务最大的影响就是必须重启服务器，这意味着业务中断。
内核热补丁：飞行中更换引擎
相比之下，内核热补丁（Live Patching）最大的优势就是无需重启，就像在一架飞行中的飞机上更换引擎零件，业务无感知地完成修复。具体而言，内核热补丁在 CVE 修复场景中有两大核心优势：
- 构建、测试和部署流程更快
- 无需重启，业务影响极小
技术框架：内核热补丁是如何工作的？
内核热补丁整体技术框架可分为三层，第一层为 kpatch工具链。kpatch 是一套用于构建和管理内核热补丁的工具。其中 Kpatch-build 是核心组件，其流程是：
- 对原始内核源码进行一次全量构建
- 打上 Patch 文件，再进行一次增量构建
- 对比二进制层面 .o 文件的差异，确定哪些函数被修改
- 将修改后的函数链接到一起，生成最终的 .ko 内核模块
- 加载这个 .ko 模块后，完成对特定函数链路的修复
第二层是 Livepatch 子系统。Kpatch 在内核中由 Livepatch 子系统支撑。该子系统在内核 4.0 及以上版本中已原生支持，其本质是通过 Ftrace 实现函数的动态重定向。第三层为 Ftrace 插桩机制。Ftrace 在编译时为每个函数的入口预留了一条空指令。在运行过程中，可以将这条空指令动态替换为跳转指令，跳转到新的函数入口，从而实现函数重定向。总体逻辑就是在内核运行过程中，替换特定函数的入口地址，使其跳转到新的函数实现。
从上游 Patch 到可加载热补丁存在一道鸿沟
上游的修复 Patch 并不能直接转化为可加载的热补丁，Kpatch 工具链对补丁有很多约束和限制：
| 约束项 | 说明 |
| 不能修改 init 函数 | 这些函数在引导阶段执行完毕后，对应内存段已被释放，无法再替换 |
| 不能修改静态分配的数据 | 例如向全局数组新增元素或变量 |
| 不能修改缺少 fentry 的函数 | 例如 lib 下的很多库函数采用静态链接，编译时未预留 fentry 入口 |
| 不能改变导出符号的签名 | 这会破坏内核 ABI，影响其他模块的调用 |
| 不能更改现有数据结构 | 例如向结构体中增加字段，运行中无法替换所有实例且风险极大 |
| 不能删除对静态局部变量的引用 | / |
由于这些约束的存在，上游修复 Patch 不能直接使用，必须经过人工改写和适配。目前这一过程完全依赖人工完成，一个 CVE 修复 Patch 可能需要数小时甚至数天才能完成改写。再加上线上存在大量不同版本的内核，每个版本迁移时还要根据基线差异进行额外调整。
当 CVE 密集涌现时，人工改写将成为瓶颈。
实战案例：copy_file 漏洞的热补丁改写
以近日公开的 copy_file 漏洞为例，我们来看看上游修复 Patch 到热补丁的实际改写过程。该漏洞源于加密模块中的一个零拷贝优化，导致越权篡改了只读的 Page Cache。攻击者可通过篡改 password 或 setuid 等文件，运行一段简单的 POC 程序即可从任意用户直接提权至 root，且影响范围时间跨度较长。
上游的修复方案是：回退 2017 年引入的零拷贝优化，改为拷贝后再写入。
上游修复的复杂度
以某个主流发行版的 5.10 内核开发分支为例，修复该 CVE 需要回合多个前置依赖 commit，最终提交包含十个 commit、十一个文件的修改，插入和删除的行数非常多。
直接构建热补丁会遇到的问题
如果直接用上游修复提交来构建热补丁，会遇到以下几类问题：
- 问题一：修改了 Kernel Config
Patch 中包含了内核配置文件的修改。Config 用于控制编译过程，这种修改不仅无意义，还会导致大量代码条件编译发生变化，产生大量不被允许的修改。而修复该漏洞实际上并不需要修改内核配置。
- 问题二：导出函数删除了参数
有两个函数删除了末尾的参数。一般情况下这种修改没有问题，但由于这两个函数是导出函数，直接删除参数相当于修改了函数签名，破坏了 ABI，这是不被允许的。
- 问题三：删除了结构体成员
有两个结构体删除了部分成员。由于属于静态数据结构，这种修改不支持——无法在加载过程中替换所有数据结构实例，也无法更改内存布局。
- 问题四：新增函数声明了导出符号
新增函数本身没有问题，但上游 Patch 中增加了导出符号的声明。内核运行时的符号表已固定，无法扩容或注册新符号，这也是不允许的。
改写策略
针对以上四类问题，我们分别采取以下改写策略：
- Config 修改 → 直接去掉，不需要改内核配置
- 删除参数 → 保留参数，仅在内部逻辑中不再使用该参数即可
- 删除结构体成员 → 保留成员不删除，不再使用即可
- 新增函数导出 → 去掉导出符号声明，函数仅在模块内部使用，不影响修复目的
改写完成后，文件变化从十一个缩减至七个，构建成功，加载后也能正常达成 CVE 修复的目的。
2026 大学生 OS 赛题要求及标准
2026 全国大学生计算机系统能力大赛中，龙蜥“内核 CVE 热补丁自动生成智能体”赛题，要求智能体能够在不改变原修复语义的基础上，自动完成补丁的改写和构建，达到高效、安全修复内核漏洞的目的。同时，高向阳也对参赛队伍提出了具体的评估标准和要求。
更多赛题详情点击右侧链接查看：龙蜥邀您参加 2026 全国大学生计算机系统能力大赛
结语
AI 不仅重塑了漏洞发现的效率，更应成为加速漏洞修复的核心驱动力。在 2026 全国大学生计算机系统能力大赛中，我们致力于推动内核热补丁技术从“人工驱动”向“智能体（Agent）驱动”的范式跃迁，通过引入 AI 智能体，旨在将热补丁的生成周期从传统的“天级”大幅压缩至“分钟级”。我们也期待各参赛队伍深耕系统底层，提出具有前瞻性与落地价值的创新解决方案。
视频回放链接：https://openanolis.cn/video/1633914108607529089
加入交流群
若你对智能运维（AIOps）、可观测性等感兴趣，欢迎搜索群号：94405014449 加入【操作系统控制台钉钉交流群】。在这里，你可以直接体验控制台最新功能，与社区大佬面对面交流最佳实践，获取第一手的技术答疑。
相关阅读文章：
开源！智能运维助手上线，SysOM MCP 为 AI Agent 打开系统诊断之门
Anolis OS 深度集成运维利器，阿里云操作系统控制台上线
—— 完 ——
