Greg KH 的本地 AI 模糊测试工具，正在批量挖出 Linux 内核漏洞

今年4月起，Linux 稳定版维护者 Greg Kroah-Hartman 开始用一套自建 AI 模糊测试系统扫描内核代码，上周末该系统又推送了一批漏洞补丁。这不是某个实验室的概念验证——补丁直接进了稳定版树，真实漏洞、真实修复、真实影响数以亿计的设备。

gkh_clanker：名字自带自嘲，效果毫不客气

Greg 把这套系统命名为 gkh_clanker。"clanker"不是什么正经术语，更像是对自家工具的调侃——但产出一点不拉垮。自4月上线以来，它持续向稳定版分支提交由 AI 辅助发现的漏洞修复，涵盖内存越界、空指针引用、竞态条件等典型内核缺陷类别。

关键细节：所有计算在本地完成。运行平台是一台配备 AMD Ryzen AI Max 处理器的 Framework Desktop 主机，不依赖任何云端 AI 服务。这意味着：

• 内核源码不需要上传到第三方服务器，避免了安全审查和许可证的灰色地带。
• 模糊测试的吞吐量受限于本地硬件，但 Greg 显然认为这个代价可以接受——Ryzen AI Max 的 NPU 单元为本地推理提供了足够算力。
• 整套流程从生成测试用例、执行到结果分析，闭环在一台机器上完成。

为什么"本地运行"这件事值得强调

内核社区对代码贡献的审计标准极高。一个 AI 工具如果依赖云端，至少面临三重阻力：

1. 代码外泄风险——内核源码含大量厂商私有驱动片段，上传到外部服务可能触发合规问题。
2. 结果可信度——云端 AI 的训练数据和推理过程不可审计，社区很难评估"这个漏洞到底是 AI 发现的还是人工复核的"。
3. 流程中断——网络延迟和 API 限流会打断模糊测试的长时间连续执行。

gkh_clanker 选择本地化，本质上是把 AI 工具纳入了内核开发既有的信任链：工具在开发者可控的环境中运行，输出仍然经过人工审查后才合入主线。AI 是加速器，不是决策者。

内核模糊测试的实战路径

gkh_clanker 的内部实现尚未公开，但内核模糊测试本身有成熟的开源工具链。最广泛使用的是 Google 维护的 syzkaller——一个专为 Linux 内核设计的覆盖率引导模糊测试器。下面展示如何用 syzkaller 搭建一个最小可运行的内核模糊测试环境。

前置准备

假设你有一台 Linux 主机（Ubuntu 22.04 或类似发行版），安装必要依赖：

# 安装编译工具链和 QEMU
sudo apt install -y gcc make qemu-system-x86 debootstrap

# 克隆 syzkaller
git clone https://github.com/google/syzkaller.git
cd syzkaller
make TARGETOS=linux TARGETARCH=amd64

编译一份带调试信息的测试内核

# 克隆稳定版内核（与 Greg 维护的分支一致）
git clone --depth 1 --branch linux-6.6.y \
  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux

# 最小化配置，启用调试与覆盖率
make defconfig
# 关键：启用 KCOV（覆盖率收集）和 KASAN（内存错误检测）
scripts/config --enable CONFIG_KCOV
scripts/config --enable CONFIG_KASAN
scripts/config --enable CONFIG_DEBUG_INFO
scripts/config --set-val CONFIG_KCOV_ENABLE_AREA_SIZE 0x100000
scripts/config --disable CONFIG_RANDOMIZE_BASE  # 方便调试

make -j$(nproc)

创建根文件系统磁盘映像

# 用 debootstrap 创建最小 Debian 系统
mkdir /tmp/syz-image
sudo debootstrap --include=openssh-server,curl,tar,gcc \
  stable /tmp/syz-image http://deb.debian.org/debian

# 设置自动登录，方便 syzkaller SSH 连接
sudo chroot /tmp/syz-image /bin/bash -c \
  'echo "root:root" | chpasswd && systemctl enable ssh'

# 打包为磁盘映像
sudo mkfs.ext4 /tmp/syz-disk.img -d /tmp/syz-image -L rootfs 4G

编写 syzkaller 配置文件

{
  "target": "linux/amd64",
  "http":    "127.0.0.1:56741",
  "workdir": "/tmp/syz-workdir",
  "kernel_obj": "/path/to/linux/",
  "image":   "/tmp/syz-disk.img",
  "syzkaller": "/path/to/syzkaller/bin/",
  "procs":   4,
  "type":    "qemu",
  "vm": {
    "count":  4,
    "cpu":    2,
    "mem":    2048,
    "kernel": "/path/to/linux/arch/x86/boot/bzImage",
    "cmdline": "console=ttyS0 root=/dev/vda rootfstype=ext4"
  },
  "enable_syscalls": [
    "openat", "read", "write", "ioctl$BINDER",
    "sendmsg$inet", "mmap", "clone"
  ]
}

enable_syscalls 可以逐步扩大范围。先聚焦几个子系统（如 binder、网络、文件系统），发现稳定后再扩展。

启动模糊测试

mkdir -p /tmp/syz-workdir
./bin/syz-manager -config=syz.cfg

启动后，syz-manager 会打开一个 Web 界面（http://127.0.0.1:56741），实时显示覆盖率曲线、崩溃统计和发现的漏洞列表。每个崩溃会自动生成最小化复现用例和 C 程序。

发现漏洞后的处理流程

# syzkaller 将崩溃报告存入 workdir/crashes/
ls /tmp/syz-workdir/crashes/

# 查看某个崩溃的描述
cat /tmp/syz-workdir/crashes/1/description

# 用最小化复现程序验证
./bin/syz-repro -config=syz.cfg -crashdir=/tmp/syz-workdir/crashes/1

拿到可复现的崩溃后，下一步就是定位根因、编写补丁、提交到内核邮件列表——这正是 Greg 每天在做的工作，只不过 gkh_clanker 替他完成了"生成测试用例并初筛"这一步。

AI + 模糊测试：加速器而非替代品

从 gkh_clanker 的运作方式可以提炼出几条对其他项目的借鉴：

值得注意的边界：

• AI 模型本身可能产生误报。gkh_clanker 的输出仍然经过 Greg 人工确认后才提交，这个环节不可省略。
• 本地推理的算力上限决定了吞吐量。Ryzen AI Max 是当前 AMD 在本地 AI 推理上的旗舰方案，但对于更大规模的项目（如全内核 syscall 空间覆盖），可能仍需多机并行。
• 模糊测试天然擅长发现内存类漏洞，但对逻辑漏洞（如权限模型设计缺陷）的覆盖有限，AI 辅助也不能完全弥补这一短板。

检查清单：想在自己的项目引入 AI 模糊测试

1. 确认目标项目有成熟的模糊测试基础设施——syzkaller 对内核、libFuzzer 对用户态库、AFL++ 对通用二进制。先让传统流程跑通，再叠加 AI。
2. 评估本地推理硬件——如果项目代码量在百万行级别，至少需要一台带 NPU 的桌面级设备；小项目用普通 GPU 即可。
3. 建立人工审查闭环——AI 输出的每一条漏洞报告，必须经过有经验的开发者确认。不要让 AI 直接提交补丁。
4. 从窄子系统开始——先对单个驱动或模块做定向模糊测试，积累置信度后再扩展到全项目。
5. 保留覆盖率基线——引入 AI 前后各跑一轮纯随机模糊测试，对比覆盖率增长曲线，量化 AI 的实际加速比。

Greg KH 用一台 Framework Desktop 证明了：AI 模糊测试不需要云，不需要大团队，不需要炫酷的 demo——只需要一个认真维护内核的人，把工具架起来，然后一条一条地把漏洞修掉。这才是工程，不是营销。