Kernel Codex Harness v2

한국어 | English

研究工具 · 原始导入：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

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

1. 先看哪里。 整个源码树对于单次模型上下文来说太大。
2. 如何处理模型产生的强发现。 本地修改、现有修复、已知 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

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

所有分类结果的 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

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

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

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

G. Design Lineage

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

III. System Architecture

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

表 I — 主要模块职责

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

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 的分类大致遵循以下优先级。

1. 溯源不可信则归为 provenance_unknown，
2. 仓库或目标为脏则归为 dirty_tree_suspect，
3. 存在相关 CVE、非否定标记，或响应指出的 fix/upstream 关系 commit 是当前 HEAD 的祖先则归为 known_issue，
4. 否则归为 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 时停止。

E. Optional syzbot Feed

kernel-harness syzbot-fetch https://syzkaller.appspot.com/upstream \
  --out artifacts/syzbot/upstream.json \
  --limit 50

kernel-harness syzbot-stats artifacts/syzbot/upstream.json --top 15

kernel-harness scan /path/to/linux \
  --profile fs \
  --syzbot-json artifacts/syzbot/upstream.json \
  --out artifacts

F. Session Artifacts

artifacts/session-<timestamp>/
├── SESSION.md
├── targets.json
├── finding_template.json
├── review_state.json
├── codex_response.txt              # 响应待处理时存在
├── bundles/
├── responses/
└── autopilot/
    ├── AUTOPILOT_STATUS.txt
    ├── AUTOPILOT_PROGRESS.txt
    ├── AUTOPILOT_BASELINE.json
    ├── AUTOPILOT_FINDINGS.txt
    ├── AUTOPILOT_FINDINGS_NEW.txt
    ├── AUTOPILOT_KNOWN_ISSUES.txt
    ├── AUTOPILOT_SUSPECTS.txt
    ├── AUTOPILOT_PROVENANCE_UNKNOWN.txt
    ├── AUTOPILOT_FINDINGS.jsonl
    ├── prompts/
    ├── exec/
    ├── parse_errors/
    └── findings/
        ├── new/
        ├── known/
        ├── suspects/
        └── unknown/

AUTOPILOT_FINDINGS.jsonl 以可后处理的形式保留 verdict、bucket、reason、branch、HEAD、溯源状态、匹配引用和 finding/archive 路径。

VI. Operational Outcome and Verification

v2 将扩展后的结构应用于实际的 Linux 内核漏洞研究。

表 II — 已公开漏洞结果

16 个回归测试并非安全检测精度基准，而是聚焦于软件契约和可部署性。

• allocator 与内置 profile 资源回归
• 否定 verdict 和普通 prose 中的 CVE 表达不会被翻转为强发现
• 手动后续限制与排名顺序
• 无待处理目标的过期响应归档
• 只读 sandbox 默认值与正向 CLI 参数
• 缺失/非 Git/状态失败的 fail-closed 溯源
• 脏目标、已知引用、否定、无关 CVE 分类
• 分类元数据的 session history 与 JSONL 保留
• parse-error 与 finding 工件契约
• 已安装 wheel 的 profile 扫描冒烟测试

python -m unittest discover -s tests -v
python -m pip wheel . --no-deps --wheel-dir dist
python -m pip install --force-reinstall dist/*.whl

GitHub Actions 在 Python 3.11 和 3.12 上运行回归测试，安装 wheel 后对 6 个打包 profile 和默认扫描进行冒烟测试。上述公开案例是实际研究中获得的运营结果，但不是代表性 Linux 树语料库上测量的 precision、recall、可利用性或 CVE 发现率基准。

VII. Safety Considerations

• Codex sandbox 默认值为 read-only，建议保持。
• 如果 clean provenance 很重要，请在 doctor 后使用 --require-clean-tree。
• 不要将非 Git 或状态/HEAD 确认失败解释为 clean。
• 除非在隔离的实验环境中，否则不要使用 --dangerously-bypass-approvals-and-sandbox。
• 源码注释和标识符也是模型输入，因此需考虑 prompt injection 的可能性。
• CVE、commit 字符串仅是响应引用，不是权威确认。
• 在公开或报告发现之前，人工必须重新验证可达性、不变量、影响和受影响版本。

VIII. Limitations and Threats to Validity

1. 词法分析。 不构建实际的 C AST、调用图或过程间数据流。
2. 分数偏差。 注释、宏、重复 token 和大文件可能对分数产生过度影响。
3. 可达性缺口。 不自动建模内核配置、权限、命名空间和设备可用性。
4. 外部数据脆弱性。 syzbot 集成受公开 HTML 结构变化的影响。
5. 仅本地溯源。 Git 祖先关系基于当前 checkout 的 HEAD，不代表所有 upstream 和 vendor 历史。
6. 响应派生引用。 CVE 和已知标记从模型响应中提取，存在遗漏、幻觉和上下文误解的可能。
7. 启发式分类。 new_candidate 和 known_issue 都不是最终新颖性判定。
8. 模型依赖性。 结果质量取决于模型、prompt 解释和可用的仓库上下文。
9. 评估范围。 当前测试验证软件回归。公开的 CVE 案例是实际使用结果，但不能替代安全检测性能的统计评估。

IX. Evolution and Retrospective

v1（仓库）专注于使用外部信号分配 LLM 注意力的问题，并在实际的 v1 辅助调查中用于发现 CVE-2026-31720。v2 延续相同的研究理念，扩展为在模型产生强发现后同时记录仓库状态和响应派生引用。使用该结构的后续调查发现了 CVE-2026-53075。

v1: source observations → rank → focused review
v2: source observations → rank → focused review → provenance-aware triage

在此演进中需要保持两条原则。

1. 不将推理前分数误解为漏洞证明。
2. 不将推理后桶误解为新颖性证明。

如果现在再次扩展，将优先考虑 Clang/tree-sitter 调用图、分数归一化、版本化 manifest 与进程间状态锁定、权威 CVE/fix 数据库适配器，以及 runner、triage、artifact writer 的分离。当前状态写入使用临时文件和原子替换。

X. Conclusion

Kernel Codex Harness v2 不替代漏洞检测。模型调用前的外部信号将调查预算分配给可解释的候选，模型调用后的溯源信号将强发现整理为可审查的队列。该结构在实际研究中用于发现 CVE-2026-53075，项目的核心成果不是自动判定新颖性的算法，而是明确分离注意力分配与溯源感知分类的实战 LLM 安全审查工作流。

Appendix A. Repository Layout

.
├── .github/workflows/ci.yml
├── docs/
│   ├── assets/kernel-harness-v2-architecture.svg
│   ├── AUTOPILOT.md
│   ├── CODEX_CLI.md
│   ├── CODEX_WORKFLOW.md
│   └── SYZBOT.md
├── kernel_harness/
│   ├── resources/
│   │   ├── linux-kernel-default.json
│   │   └── profiles/
│   │       ├── bpf.json
│   │       ├── drivers.json
│   │       ├── fs.json
│   │       ├── io_uring.json
│   │       └── net.json
│   ├── __init__.py
│   ├── __main__.py
│   ├── autopilot.py
│   ├── bundle.py
│   ├── cli.py
│   ├── finding_triage.py
│   ├── ingest.py
│   ├── models.py
│   ├── prompting.py
│   ├── repo_state.py
│   ├── session.py
│   ├── syzbot.py
│   └── targeting.py
├── tests/test_regressions.py
├── .gitignore
├── README.md
└── pyproject.toml

详细的手动操作请参阅 Codex CLI 指南，自动执行与分类请参阅 Autopilot 指南，crash intelligence 请参阅 syzbot 指南。

References

[1] Protect AI, “vulnhuntr,” GitHub repository. https://github.com/protectai/vulnhuntr

[2] Google, “syzkaller and syzbot,” GitHub repository. https://github.com/google/syzkaller

[3] OpenAI, “Codex CLI.” https://developers.openai.com/codex/cli/

License

Licensed under the Apache License 2.0.