00 · 总览:分清六件事 + 选型决策
为什么先分类
"检测内核安全漏洞"被日常语言压成一句话,实际是手段完全不同的几件事。选错类别 = 选错工具。最常见的混淆:把"检测 CVE"(静态查有没有洞)和"影响评级"(判断一个洞实际有多严重)当一回事。
本库实践 ①②③⑤⑥(检测 / 加固 / 挖洞→修 / 审计 / 逆向),对自有或授权目标做,目的是修复。④ 是参考类,只用于影响评级,不放攻击工具。
六件事对照
| # | 活动 | 回答的问题 | 输入 | 输出 | 是不是 LLM 主场 |
|---|---|---|---|---|---|
| ① | 已知 CVE 检测 | 我内核里有没有已公开的 CVE? | 内核源码 / 版本 / git | 一份"命中/未修 CVE"清单 | ❌ 确定性工具主场 |
| ② | 配置加固检查 | 我内核配置够不够硬? | .config / cmdline / sysctl |
缺失的加固选项清单 | ❌ 规则比对 |
| ③ | 新漏洞挖掘 | 有没有还没人发现的洞? | 内核源码 + 可跑的内核 | 崩溃 / 新 bug / 新 CVE | ⭕ LLM 配 fuzzer |
| ④ | 影响评级(参考类) | 这个洞实际影响多大、要不要先修? | 资料合集 + 漏洞类别知识 | 严重度/优先级评级 | ❌ 靠人工判断 |
| ⑤ | LLM 审代码/补丁(辅助) | 这段 diff 有没有安全问题? | 代码 / diff | 疑似漏洞点 + 说明 | ⭕ LLM 主场 |
| ⑥ | 二进制逆向 | 只有 .ko/固件,或要证明出厂二进制含 bug |
.ko / 固件 |
汇编级坐实的 bug | 辅助 |
①检测 vs ④影响评级:一定要分清
| ① 已知 CVE 检测 | ④ 影响评级(参考类) | |
|---|---|---|
| 动作 | 静态读源码/查版本,不运行 | 对照资料合集,判断这个洞能造成多大影响 |
| 需不需要目标在跑 | 不需要,拿源码就行 | 不需要——本库只做纸面评级,不实跑攻击 |
| 产出 | "你这版本/源码里有 CVE-XXXX" | "CVE-XXXX 在这台设备上够得着/够不着 → 定级中危" |
| 授权风险 | 低(审自己代码) | 低(纸面评级);若真要实验证明必须书面授权 |
一句话:①告诉你"门可能没锁",④判断"这扇没锁的门后面有没有值钱东西,值不值得先去修锁"。
选型决策树
你想干嘛?
├─ 知道"我这内核中了哪些已公开 CVE"
│ ├─ 内核有 git 历史且基于 stable 标签 → kernel-cve-tool(查修复 commit 在不在)
│ └─ 内核是源码包 / 想抓漏掉 SUBLEVEL 的 backport → cvehound(源码模式匹配)
│ └─ 两者互补,vendor 内核建议都跑 → 见 docs/01
├─ 知道"我配置留了哪些可被利用的软肋" → kernel-hardening-checker → docs/02
├─ 想挖"还没人发现的新洞"(研究级,重) → KernelGPT + syzkaller → docs/03
├─ 想评估"某 CVE 在我设备上实际影响多大、要不要先修" → 影响评级,资料合集 → docs/04
└─ 想让 Claude 帮我审内核补丁/代码找隐患 → claude-code-security-review / trailofbits → docs/05
LLM 的诚实定位
- ①②④ 不是 LLM 主场:确定性工具(coccinelle 规则、git commit 比对、config 规则)和人工影响评级才是核心。
- LLM 的价值在辅助:后处理过滤假阳性、解释 CVE 成因与可达性、判断 vendor backport 状态。
- ③里 LLM 是关键一环:生成 syscall 描述、理解调用语义,把实跑触发交给 syzkaller。
- 别指望"让 Claude 读整棵内核源码直接报洞"——误报高、几千万行塞不进上下文。实产 CVE 的 SOTA 都是 LLM 配 fuzzer / 静态 checker / CodeQL。
在你自己内核上的落点
典型形态:一棵 vendor arm64 内核源码,有 git 历史,基于某个 6.1.x LTS 标签。→ ① 用 cvehound + kernel-cve-tool 双跑,② 用 kernel-hardening-checker(arm64),⑤ 用 Claude 过结果。详见各分类文档和根 README。