Kernel Codex Harness v2

研究工具 · 原始导入：2026年4月3日 · v2 文档修订：2026年7月11日

外部信号：从注意力分配到溯源感知分类
使用可复现的观察结果引导模型注意力，然后使用仓库溯源组织审查队列——绝不用于声称证明。

项目谱系—— Kernel Codex Harness v1 · 注意力分配 → Kernel Codex Harness v2 · 溯源感知分类

项目状态。 本仓库是一个 LLM 辅助研究工具，将 v1 的注意力分配工作流发展为溯源感知分类，用于实际的 Linux 内核漏洞研究。此版本被用于发现以 CVE-2026-53075 公开的漏洞。它不是自动漏洞检测器、新颖性判定器、exploit 验证器或内核安全保证工具，最终验证和报告由人工完成。

Abstract

摘要—— 让 LLM 直接探索像 Linux 内核这样的大型代码库会导致上下文分散，并且容易混淆危险 API 的存在与实际可利用性。Kernel Codex Harness v2 将这个问题定义为两个阶段的外部信号处理。在模型调用之前，通过路径权重、词法命中、缓存的 syzbot 重叠对候选文件进行排序以分配注意力。在模型响应之后，将 Git 分支、HEAD、脏状态与从响应中提取的 CVE、commit、已知标记相结合，将强发现分类到溯源感知的审查桶中。该工具在实际 Linux 内核研究中被用于发现 PPP 的目标网络命名空间权限验证缺陷，该缺陷已以 CVE-2026-53075 公开。分类是整理研究队列的启发式方法，特别是 new_candidate 仅表示未发现已知线索或溯源问题，并非新颖性证明。所有发现都要求人工重新验证 userspace 可达性、不变量破坏和具体影响。

索引术语—— Linux 内核、漏洞研究、外部信号、溯源、启发式分类、LLM 编排、syzbot、Codex。

I. Introduction

内核安全审查存在两种不同类型的不确定性。

先看哪里。 整个源码树对于单次模型上下文来说太大。
如何处理模型产生的强发现。 本地修改、现有修复、已知 CVE 或不完整的仓库状态都可能污染结论。

v1 的核心问题是第一个，即注意力分配。v2 在保留该原则的同时，将第二个问题扩展为溯源感知分类。两个版本均用于实际研究，v1 辅助调查促成了 CVE-2026-31720，v2 辅助调查促成了 CVE-2026-53075。

使用模型之外的观察值缩小研究范围，在模型响应之后附加可验证的仓库溯源。任何阶段的信号都不证明漏洞或新颖性。

II. External Signal and Design Principles

A. Stage 1 — Attention Allocation Before Inference

推理前外部信号是模型执行前计算的观察值，而非 LLM 判断。

内核路径与子系统权重
usercopy、allocator、refcount、size、lock 等词法命中
存储的 syzbot JSON 的文件/子系统重叠

使用相同的源码树、profile 和缓存的 syzbot JSON 可以重新计算候选排名。该分数不是概率或可利用性，而是决定先看哪里的相对顺序。

B. Stage 2 — Provenance-Aware Triage After Inference

推理后阶段将以下信息与强模型判定相结合。

Git 仓库是否存在以及状态收集是否成功
分支与 HEAD
仓库及目标文件的脏状态
从响应中提取的 CVE、commit hash、已知问题标记
响应中出现的否定或无关引用表达

在本文档中，推理后外部信号仅指独立于模型收集的溯源信息，如 Git 仓库/状态、分支、HEAD、脏状态、本地 commit 祖先关系。CVE、commit、已知标记是从模型响应中提取的模型派生引用，不是外部信号或权威事实。分类结合两类输入，但区分并记录其来源。

C. Heuristic Buckets, Not Novelty Proof

强发现按操作划分为以下审查桶之一。

Bucket	Meaning
`new_candidate`	溯源已确认且未发现脏/已知阻塞信号的候选
`known_issue`	存在非否定的已知引用，或响应指出 fix/upstream 关系且该 commit 已包含在当前 HEAD 中的候选
`dirty_tree_suspect`	无法排除脏仓库或脏目标影响的候选
`provenance_unknown`	无法可靠确认 Git 仓库、状态或 HEAD 的候选

所有分类结果的 novelty_proven 均为 false。new_candidate 不是“新漏洞”，而是优先由人工继续新颖性调查的队列。

D. Reachability Before Bug Class

审计首先确认从 userspace 开始的边界，如 syscall、ioctl、netlink、procfs、文件系统、BPF、驱动钩子。之后才评估 UAF、OOB、refcount、race、信息泄露、能力检查等 bug class。

E. One Investigation Branch at a Time

一个调查单元限制为一个文件及其邻近的 caller、teardown、free 路径。模型建议的手动后续操作最多限制为两次，以保持可验证的短路径而非广泛探索。

F. Evidence Over Confidence

强发现至少应说明以下内容。

attacker 可达的入口点，
attacker 控制的字段或生命周期转换，
被破坏的对象、长度或状态不变量，
破坏、泄露、权限提升等具体影响，
现有检查无法阻止攻击的原因。

解析器仅规范化 verdict 和下一个目标，不会自动证明这些证据的完整性。

G. Design Lineage

初始流程源于 Protect AI 的 vulnhuntr 使用的文件级分析、受限上下文扩展和结构化输出思想 [1]。在本项目中，我们针对 userspace 可达的内核表面、内核对象生命周期、teardown 路径和 syzbot 重叠重新设计了这些思想。v2 的额外贡献是在注意力分配之后增加了基于仓库溯源的发现分类阶段。

III. System Architecture

Two-stage External Signal architecture for Kernel Codex Harness v2

图 1. 推理前外部信号对可复现的审查单元进行排序。推理后分类将独立于模型的 Git 溯源与模型派生的响应引用相结合，而不将后者视为外部信号或权威事实。人工验证仍处于两个自动化阶段之外。

表 I — 主要模块职责

Module	Responsibility
`targeting.py`	内核文件探索与路径、词法、syzbot 信号评分
`models.py`	`Candidate`、`Signal`、syzbot 派生的 `ExternalSignal`
`bundle.py`	manifest、session index、prompt/snippet bundle 生成
`prompting.py`	以可达性和不变量为中心的内核审计提示
`session.py`	待审查、历史、后续深度状态存储
`ingest.py`	严格 verdict 与单一下一个目标规范化
`repo_state.py`	Git 分支、HEAD、状态、脏路径、祖先关系收集
`finding_triage.py`	基于溯源与已知引用的启发式桶分类
`autopilot.py`	基于时间预算的 Codex 执行、ingest、归档、发现记录
`syzbot.py`	公开 syzbot HTML 收集与本地 JSON cache 生成
`cli.py`	scan/review/doctor/autopilot 命令连接

IV. Methodology

A. Candidate Discovery and Scoring

扫描器遍历 profile 的 include 目录下的 .c 和 .h 文件。

Score(f) = Σ path_weight(f)
         + Σ line_signal_weight(f)
         + Σ syzbot_overlap_weight(f)

当前实现累加行级匹配，并仅限制在 prompt 中显示的最高信号数量。score 决定模型的调查顺序，但不是经过校正的漏洞可能性统计值。

主要静态信号如下。

ioctl、compat handler、文件操作钩子
copy_from/to_user 与 __user
kmalloc/kzalloc/kvmalloc、cache 分配与 free 路径
refcount、atomic、kref
size、length 计算与 memcpy 系列
lock、RCU、异步生命周期
BPF、skb、XDP、netlink
能力与命名空间检查

B. Profile-Driven Scope

Profile	Focus
`default`	kernel/mm/net/fs/security/io_uring/lib/drivers 起点
`net`	netlink、socket、skb、XDP
`fs`	ioctl、procfs、seq_file、debugfs
`io_uring`	异步请求生命周期与 teardown
`bpf`	verifier、map/program 生命周期、BTF
`drivers`	ioctl、DMA、MMIO 与驱动 teardown

C. Crash Intelligence

syzbot-fetch 从公开的 syzbot bug 页面提取标题、子系统、bug 类型、file:line 并保存为 JSON。精确文件重叠是强排名信号，子系统重叠是弱信号。实时仪表板可能变化，因此可复现单元是抓取时保存的 JSON。Crash 重叠是变体狩猎的提示，而非漏洞证据。

D. Session and Review Contract

scan 生成完整的排名候选 manifest 和顶部 prompt bundle。--limit 是 manifest 中保留的候选数量，--top 是预生成的 bundle 数量。后续排名也可按需生成。

模型响应被规范化为以下 verdict 之一。

cve_candidate
plausible_security_bug
latent_bug
not_cve_candidate
needs_more_context

手动 review 和 autopilot 使用相同的 review_state.json、固定响应路径和 verdict 解析器。

E. Provenance Collection and Triage

doctor 和 autopilot 检查 Git 仓库是否存在、状态收集是否成功、分支、HEAD 和脏路径。无法确认溯源的状态不会被视为 clean，而是保留为 provenance_unknown。

强 verdict 的分类大致遵循以下优先级。

溯源不可信则归为 provenance_unknown，
仓库或目标为脏则归为 dirty_tree_suspect，
存在相关 CVE、非否定标记，或响应指出的 fix/upstream 关系 commit 是当前 HEAD 的祖先则归为 known_issue，
否则归为 new_candidate。

“not a known issue”、“unrelated to CVE-…” 等否定或无关表达不作为已知依据。最终判定中保留原始 verdict 以及 branch、HEAD、status、dirty state、匹配引用和原因。

当前溯源感知桶分类和 JSONL writer 应用于 autopilot ingest 路径。手动 loop 和 ingest 使用相同的基础 session state 和 verdict 解析器，但不生成桶工件。

V. Implementation and Usage

A. Requirements

Python 3.11 或更高版本
Linux 内核源码树
使用 provenance/doctor/autopilot 时需要 Git
使用 autopilot 时需要 Codex CLI 和认证 [3]
远程 syzbot 收集时需要网络连接

Python 运行时依赖仅为标准库。

B. Installation

git clone https://github.com/foxirain/linux-kernel-codex-harness-v2.git
cd linux-kernel-codex-harness-v2

python3 -m venv .venv
source .venv/bin/activate
python -m pip install .
kernel-harness --help

内置 profile JSON 包含在 wheel 中。可通过 --config /path/to/profile.json 传入自定义规则。

C. Minimal Workflow

# 1. 验证仓库溯源。
kernel-harness doctor /path/to/linux

# 2. 创建排名会话。
kernel-harness scan /path/to/linux \
  --profile net \
  --limit 80 \
  --top 20 \
  --out artifacts

# 3. 检查并渲染一个聚焦审查。
kernel-harness inspect artifacts/session-YYYYMMDDTHHMMSSZ --top 10
kernel-harness codex artifacts/session-YYYYMMDDTHHMMSSZ \
  --rank 1 \
  --include-snippet

手动 Codex 响应保存到 runbook 指定的 codex_response.txt 后，可通过以下命令 ingest。

kernel-harness loop artifacts/session-YYYYMMDDTHHMMSSZ --include-snippet
kernel-harness status artifacts/session-YYYYMMDDTHHMMSSZ

D. Time-Budgeted Autopilot

kernel-harness autopilot artifacts/session-YYYYMMDDTHHMMSSZ \
  --duration 30m \
  --per-run-timeout 10m \
  --include-snippet \
  --require-clean-tree \
  --stop-on-finding

Codex sandbox 默认值为 read-only。--require-clean-tree 仅在 Git 仓库、状态、HEAD 已确认且工作树干净时允许执行。--stop-on-finding 仅在启发式分类结果为 new_candidate 时停止。

linux-kernel-codex-harness-v2

最受欢迎