Kernel Codex Harness v2

한국어 | English

研究ツール · オリジナルインポート: 2026年4月3日 · v2 ドキュメント改訂: 2026年7月11日

外部シグナル: 注意配分から来歴認識型トリアージへ
再現可能な観測値を使ってモデルの注意を導き、その後リポジトリの来歴を使ってレビューキューの整理を行う——証明を主張するためではない。

プロジェクト系統— Kernel Codex Harness v1 · 注意配分 → Kernel Codex Harness v2 · 来歴認識型トリアージ

プロジェクトステータス. このリポジトリは、実際のLinuxカーネル脆弱性調査のためにv1のattention-allocationワークフローをprovenance-aware triageまで発展させたLLM支援型リサーチハーネスです。このバージョンはCVE-2026-53075として公開された脆弱性の発見に使用されました。自動脆弱性検出器、新規性判定器、exploit検証器、またはカーネルセキュリティ保証ツールではなく、最終的な検証と報告は人間が行います。

Abstract

Abstract— Linuxカーネルのような大規模コードベースをLLMにそのまま探索させるとコンテキストが分散し、危険なAPIの存在と実際の攻撃可能性が容易に混同されます。Kernel Codex Harness v2はこの問題を2段階のExternal Signal処理として定義します。モデル呼び出し前には、パスweight、lexical hit、キャッシュされたsyzbot overlapで候補ファイルをランク付けしてattentionを配分します。モデル応答後には、Git branch・HEAD・dirty stateと応答から抽出したCVE・commit・known markerを組み合わせて、strong findingをprovenance-aware review bucketに分類します。このハーネスは実際のLinuxカーネル調査でPPPのtarget network namespace権限検証欠陥を発見するために使用され、その欠陥はCVE-2026-53075として公開されました。Triageは調査キューを整理するheuristicであり、特にnew_candidateは既知の手掛かりやprovenance問題を発見できなかったことを意味するだけで、novelty proofではありません。すべてのfindingはuserspace reachability、invariant break、concrete impactについて人間による再検証を要求します。

Index Terms— Linux kernel, vulnerability research, external signal, provenance, heuristic triage, LLM orchestration, syzbot, Codex.

I. Introduction

カーネルセキュリティレビューには、互いに異なる2種類の不確実性があります。

1. どこを最初に見るか。 ソースツリー全体は1回のモデルコンテキストで扱うには大きすぎます。
2. モデルが出したstrong findingをどう扱うか。 ローカル修正、既存fix、既知のCVE、または不完全なリポジトリ状態が結論を汚染する可能性があります。

v1の中心問題は最初のもの、つまりattention allocationでした。v2はその原則を維持しながら、2番目の問題をprovenance-aware triageへ拡張します。両バージョンはそれぞれ実際の調査に使用され、v1-assisted investigationはCVE-2026-31720に、v2-assisted investigationはCVE-2026-53075につながりました。

モデル外部の観測値で調査範囲を絞り込み、モデル応答後には検証可能なリポジトリprovenanceを付与します。いずれの段階のsignalも脆弱性または新規性を証明しません。

II. External Signal and Design Principles

A. Stage 1 — Attention Allocation Before Inference

Pre-inference External SignalはLLMの判断ではなく、モデル実行前に計算される観測値です。

• カーネルパスとsubsystem weight
• usercopy、allocator、refcount、size、lockなどのlexical hit
• 保存されたsyzbot JSONのfile/subsystem overlap

同じsource tree、profile、キャッシュされたsyzbot JSONを使用すればcandidate rankを再計算できます。このスコアは確率やexploitabilityではなく、どこを最初に見るかを決める相対的な順序です。

B. Stage 2 — Provenance-Aware Triage After Inference

Post-inference段階では、strong model verdictに以下の情報を組み合わせます。

• Gitリポジトリかどうかとstatus収集の成功有無
• branchとHEAD
• リポジトリおよびtarget fileのdirty state
• 応答から抽出したCVE、commit hash、known-issue marker
• 応答に現れたnegationまたはunrelated-reference表現

このドキュメントでpost-inference External Signalとは、Git repository/status、branch、HEAD、dirty state、local commit ancestryのようにモデルと独立に収集したprovenanceのみを指します。CVE・commit・known markerはモデル応答から抽出したmodel-derived referenceであり、External Signalやauthoritative factではありません。Triageは2種類の入力を組み合わせますが、その出所を区別して記録します。

C. Heuristic Buckets, Not Novelty Proof

Strong findingは運用上、次のreview bucketのいずれかに整理されます。

すべての分類結果のnovelty_provenはfalseです。new_candidateは「新しい脆弱性」ではなく、優先的に人間が新規性調査を継続するキューを意味します。

D. Reachability Before Bug Class

監査はsyscall、ioctl、netlink、procfs、filesystem、BPF、driver hookのようにuserspaceから始まる境界を最初に確認します。その後にUAF、OOB、refcount、race、info leak、capability checkなどのbug classを評価します。

E. One Investigation Branch at a Time

1つの調査単位は1つのファイルと近接するcaller・teardown・free pathに限定します。モデルが提案するmanual follow-upは最大2回に制限し、広範な探索よりも検証可能な短いパスを維持します。

F. Evidence Over Confidence

強いfindingは最低限以下を説明する必要があります。

1. attacker-reachable entrypoint、
2. attacker-controlled fieldまたはlifetime transition、
3. 破壊されるobject・length・state invariant、
4. corruption、leak、privilege escalationなどの具体的なimpact、
5. 既存のcheckが攻撃を防げない理由。

Parserはverdictとnext targetを正規化するだけで、この証拠の完全性を自動証明しません。

G. Design Lineage

初期フローはProtect AIのvulnhuntrが使用したファイル単位分析、制限付きコンテキスト拡張、構造化された成果物という発想から始まりました [1]。このプロジェクトではこれをuserspace-reachable kernel surface、カーネルオブジェクトlifetime、teardown path、syzbot overlapに合わせて再設計しました。v2の追加貢献はattention allocationの後にリポジトリprovenanceを用いたfinding triage段階を置いたことです。

III. System Architecture

Fig. 1. Pre-inference External Signalは再現可能なreview unitをランク付けします。Post-inference triageはモデル独立のGit provenanceとモデル由来の応答referenceを組み合わせますが、後者をExternal Signalやauthoritative factとして扱いません。人間による検証は両自動段階の外に残ります。

TABLE I — MAJOR MODULE RESPONSIBILITIES

IV. Methodology

A. Candidate Discovery and Scoring

スキャナーはprofileのinclude directory以下の.cと.hファイルを走査します。

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

現在の実装はline-level matchを合算し、promptに表示する上位シグナル数のみを制限します。scoreはモデルの調査順序を決めますが、vulnerability likelihoodを補正した統計値ではありません。

主な静的シグナルは以下の通りです。

• ioctl、compat handler、file operation hook
• copy_from/to_userと__user
• kmalloc/kzalloc/kvmalloc、cache allocationとfree path
• refcount、atomic、kref
• size・length計算とmemcpy系
• lock、RCU、async lifetime
• BPF、skb、XDP、netlink
• capabilityとnamespace check

B. Profile-Driven Scope

C. Crash Intelligence

syzbot-fetchは公開syzbot bug pageからtitle、subsystem、bug type、file:lineを抽出してJSONに保存します。exact file overlapは強いranking signal、subsystem overlapは弱いsignalとして使用します。Live dashboardは変化しうるため、再現単位はfetch時点の保存済みJSONです。Crash overlapはvariant huntingのヒントであり、脆弱性の証拠ではありません。

D. Session and Review Contract

scanは全体のranked candidate manifestと上位prompt bundleを生成します。--limitはmanifestに保持するcandidate数、--topは事前生成するbundle数です。それ以降のrankも要求時に生成できます。

モデル応答は次のverdictのいずれかに正規化されます。

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

手動reviewとautopilotは同じreview_state.json、固定response path、verdict parserを使用します。

E. Provenance Collection and Triage

doctorとautopilotはGitリポジトリかどうか、status収集の成功有無、branch、HEAD、dirty pathを確認します。Provenanceを確定できない状態はcleanと見なさず、provenance_unknownとして保持します。

Strong verdictのtriageはおおよそ次の優先順位に従います。

1. provenanceを信頼できない場合はprovenance_unknown、
2. リポジトリまたはtargetがdirtyの場合はdirty_tree_suspect、
3. 関連するCVE・non-negated markerがあるか、応答がfix/upstream関係として指摘したcommitが現在のHEAD ancestorであればknown_issue、
4. それ以外はnew_candidate。

「not a known issue」「unrelated to CVE-…」のような否定・非関連表現はknownの根拠として使用しません。最終判定には元のverdictとともにbranch、HEAD、status、dirty state、matched reference、reasonを残します。

現在のprovenance-aware bucket分類とJSONL writerはautopilot ingestパスに適用されます。手動のloopとingestは同じ基本session stateとverdict parserを使用しますが、bucket artifactは作成しません。

V. Implementation and Usage

A. Requirements

• Python 3.11以上
• Linux kernel source tree
• provenance/doctor/autopilot使用時のGit
• autopilot使用時のCodex CLIと認証 [3]
• リモートsyzbot収集時のネットワーク接続

Python runtime依存は標準ライブラリのみです。

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. Verify repository provenance.
kernel-harness doctor /path/to/linux

# 2. Create a ranked session.
kernel-harness scan /path/to/linux \
  --profile net \
  --limit 80 \
  --top 20 \
  --out artifacts

# 3. Inspect and render one focused review.
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 repository、status、HEADが確認され、working treeがcleanな場合のみ実行を許可します。--stop-on-findingはheuristic triage結果が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              # responseがpendingのときに存在
├── 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、provenance状態、matched reference、finding/archiveパスを後処理可能な形式で保持します。

VI. Operational Outcome and Verification

v2は拡張された構造を実際のLinuxカーネル脆弱性調査に適用しました。

TABLE II — DISCLOSED VULNERABILITY OUTCOME

16個のregression testはセキュリティ検出精度のbenchmarkではなく、software contractと配布可能性に焦点を当てています。

• allocatorと組み込みprofile resourceの回帰
• negative verdictと一般的なproseのCVE表現がstrong findingに反転しないか
• manual follow-up制限とrank ordering
• pending targetのないstale response archive
• read-only sandboxデフォルトとpositive CLI引数
• missing/non-Git/status-failureのfail-closed provenance
• dirty target、known reference、negation、unrelated CVE triage
• classification metadataのsession historyおよびJSONL保持
• parse-errorとfinding artifact契約
• インストール済みwheelでのprofile scan smoke test

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でregression testを実行し、wheelをインストールした後、6個のpackaged profileとdefault scanをsmoke-testします。上記の公開事例は実際の調査で得られたoperational outcomeですが、代表的なLinux tree corpusで測定したprecision、recall、exploitability、またはCVE discovery rate benchmarkではありません。

VII. Safety Considerations

• Codex sandboxのデフォルトはread-onlyであり、維持することを推奨します。
• clean provenanceが重要な場合はdoctor後に--require-clean-treeを使用します。
• non-Gitまたはstatus/HEAD確認失敗をcleanと解釈しません。
• --dangerously-bypass-approvals-and-sandboxは隔離された実験環境以外では使用しません。
• source commentとidentifierもモデル入力であるため、prompt injectionの可能性を考慮します。
• CVE・commit文字列は応答referenceであり、authoritative confirmationではありません。
• finding公開または報告前に、人間がreachability、invariant、impact、affected versionを再検証します。

VIII. Limitations and Threats to Validity

1. Lexical analysis. 実際のC AST、call graph、interprocedural data flowを構築しません。
2. Score bias. コメント、マクロ、反復token、大きなファイルがスコアに過度な影響を与える可能性があります。
3. Reachability gap. kernel config、privilege、namespace、device availabilityを自動モデル化しません。
4. External data fragility. syzbot統合は公開HTML構造の変更の影響を受けます。
5. Local provenance only. Git ancestryは現在のcheckoutのHEADを基準とし、すべてのupstream・vendor historyを代表しません。
6. Response-derived references. CVEとknown markerはモデル応答から抽出されるため、欠落・幻覚・文脈誤解の可能性があります。
7. Heuristic triage. new_candidateとknown_issueはいずれも最終的な新規性判定ではありません。
8. Model dependence. 結果品質はモデル、prompt interpretation、利用可能なrepository contextに依存します。
9. Evaluation scope. 現在のテストはsoftware regressionを検証します。公開されたCVE事例は実際の使用結果ですが、security detection性能の統計的評価を代替しません。

IX. Evolution and Retrospective

v1(repository)はExternal SignalでLLM attentionを配分する問題に集中し、実際のv1-assisted調査でCVE-2026-31720を発見するために使用されました。v2は同じ研究哲学を継承し、モデルがstrong findingを出した後もrepository stateとresponse-derived referenceを一緒に記録するよう拡張しました。この構造を使用した後続調査ではCVE-2026-53075が発見されました。

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

この発展で維持すべき原則は2つです。

1. pre-inference scoreをvulnerability proofと誤解しない。
2. post-inference bucketをnovelty proofと誤解しない。

今再び拡張するなら、Clang/tree-sitter call graph、score normalization、versioned manifestとinter-process state locking、authoritative CVE/fix database adapter、runner・triage・artifact writerの分離を優先します。現在のstate write自体はtemporary fileとatomic replaceを使用します。

X. Conclusion

Kernel Codex Harness v2は脆弱性検出を代替しません。モデル呼び出し前のExternal Signalは調査予算を説明可能な候補に配分し、モデル呼び出し後のprovenance signalはstrong findingをレビュー可能なキューに整理します。この構造は実際の調査でCVE-2026-53075の発見に使用され、プロジェクトの核心結果は新規性を自動判定するアルゴリズムではなく、attention allocationとprovenance-aware triageを明示的に分離した実戦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 guide、自動実行とtriageはAutopilot guide、crash intelligenceはsyzbot guideで確認できます。

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.