01 · 已知 CVE 检测

目标:给定一棵内核源码 / 一个内核版本,查出它里面有哪些已经公开、有 CVE 编号的漏洞没修。这是"检测 CVE 这种安全漏洞"的正解。

对 vendor 内核最大的坑:版本号骗人。厂商在某个 LTS 上叠自己的补丁,可能 backport 了上游修复却不 bump 版本号,也可能自带驱动引入上游没有的 bug。所以"按版本号匹配 CVE"这条路在 vendor 内核上误判高。真正靠谱的是看源码 / 看 commit。

工具对比

工具	原理	需要 git 历史?	强项	弱项
cvehound	coccinelle/grep 规则,在源码里找漏洞代码模式在不在 / 修复补丁打了没	不需要	vendor 源码包、抓漏掉 SUBLEVEL 的 backport	只覆盖有规则的 CVE(规则库有限)
kernel-cve-tool	用 linux_kernel_cves 数据集,查CVE 修复 commit 是否已进你的分支	需要	有 git 历史的下游内核,精确到 commit	依赖分支从 stable 标签派生
linux_kernel_cves	CVE ↔ 修复 commit 映射数据库(非扫描器)	—	给上面两个当数据源 / 手查	本身不扫你的树
Vuls	按包版本号匹配 CVE(系统级 agentless)	不需要	整机/发行版扫描	vendor 内核版本对不上,误判高,故未克隆

cvehound(vendor 内核首选)

来源:github.com/evdenis/cvehound · 本地:repos/01-known-cve-detection/cvehound/

它解决什么:很多厂商把内核当源码包发,没有开发 git log。Makefile 里的版本串只能告诉你"上游到这个版本修了哪些 CVE",不能告诉你厂商自己 backport 了什么。cvehound 直接查源码里"未修的 CVE 代码"或"缺失的修复"。

判定两种形态:

查"未修代码还在不在"(如 CVE-2020-12912.cocci)
查"修复补丁在不在"(如 CVE-2020-26088.cocci,缺 = 有洞)

依赖:Python ≥ 3.11 · grep 带 pcre(-P)· coccinelle ≥ 1.0.7(scripts/install-deps.sh 会装)

跑:

pip install --user cvehound          # 或 scripts/install-deps.sh 一起装
cvehound --kernel "$KERNEL"          # $KERNEL = 你的内核源码目录
# 命中形如: Found: CVE-2020-27830

它自己发现过的真问题(README 列):CVE-2020-27825 / CVE-2021-4149 / CVE-2022-26490 / CVE-2023-1989 等在多个 stable 树缺 backport——说明它确实能抓 backport 遗漏,正是 vendor 内核的痛点。

kernel-cve-tool(有 git 历史时更精确)

来源:github.com/madisongh/kernel-cve-tool · 本地:repos/01-known-cve-detection/kernel-cve-tool/

它解决什么:review 一个有 git 历史的下游内核,查哪些 CVE 修复 commit 已 cherry-pick 进来。要求你的分支从某个 stable 标签(如 v6.1)派生。

流程:

# 1. 你的内核要有 git,加 linux-stable 远程并 fetch
cd "$KERNEL"
git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable          # 大,耗时;给它定位 fix commit 用

# 2. linux_kernel_cves 数据集(clone-tools.sh 已克隆到 repos/)
# 3. 跑(数据源指到本库 repos/ 下那份)
kernel-cve-tool -P "$LKSEC/repos/01-known-cve-detection/linux_kernel_cves"

输出(当前目录生成 3 个文件):

PATCHED-CVES — 已修的
NO-FIXES-AVILABLE — 无补丁可用的(原文这么拼)
cherry-picks.list — 可手动 cherry-pick 的 git hash

原理:解析顶层 Makefile 拿基础版本,读 linux_kernel_cves 的 JSON,对每个"疑似未修" CVE 在你分支里找对应 fix commit。跑一遍要几分钟。

linux_kernel_cves(数据库,不是扫描器)

来源:github.com/nluedtke/linux_kernel_cves · 本地:repos/01-known-cve-detection/linux_kernel_cves/

上游内核 CVE 的追踪数据集,JSON + 文本,web 前端 linuxkernelcves.com。给 kernel-cve-tool 当数据源,也能自己按 stream 查。

README 的一句实话值得记:"你可以修光所有已知 CVE,仍然可能被攻破。" 已知 CVE 检测只是内核安全的一小块,配置加固(docs/02)和新洞挖掘(docs/03)是另外的维度。

建议流程

cvehound 先扫 $KERNEL,拿一份源码级命中清单(抓 backport 遗漏)。
kernel-cve-tool 再跑(利用 git 历史 + linux-stable),交叉验证哪些 fix commit 真进了分支。
两份清单求并 + 差异分析:cvehound 报命中但 kernel-cve-tool 说已 patch → 多半是 vendor 用不同 commit/backport 修了,cvehound 规则没识别 → 用 ⑤ Claude 逐条判真假(见 docs/05)。
剩下的真命中,按可达性(要不要本地权限、特定 config、特定驱动是否编入)排优先级。

变量约定:$KERNEL = 你的内核源码目录;$LKSEC = 本库根目录。