Kernel Codex Harness

한국어 | English

研究ツール · 初回インポート: 2026年4月3日 · ドキュメント改訂: 2026年7月11日

中核哲学 — 外部シグナル
モデル推論の外部で計算された再現可能な観測値に注意を向けさせ、優先度を証明と誤解してはならない。

プロジェクトの状態。 このリポジトリは、実際のLinuxカーネル脆弱性調査のために構築・使用したLLM支援型リサーチハーネスの初期バージョンです。このバージョンは、CVE-2026-31720として公開された脆弱性の発見に使用されました。ハーネスは調査対象の優先順位付けを行いますが、脆弱性を自動的に証明したり、カーネルのセキュリティを保証したりするものではなく、最終的な検証と報告は人間が行います。

Abstract

Abstract— Linuxカーネルのような大規模なコードベースをLLMにそのまま探索させると、コンテキストが急速に散漫になり、危険なAPIの存在と実際の攻撃可能性が容易に混同されます。Kernel Codex Harnessは、この問題を脆弱性の自動検出ではなく、調査の優先順位決定と状態ベースのオーケストレーションの問題として定義します。このプロジェクトは、LLM推論の外部で計算された再現可能な観測値によってモデルの注意を制御する原則をExternal Signalと呼びます。カーネルパス、userspace境界、lifetime・usercopy・refcount・size関連の静的シグナルと、オプションのsyzbotクラッシュインテリジェンスを組み合わせて候補ファイルをランク付けし、各候補を狭いプロンプトバンドルに変換します。手動レビューと時間予算ベースのオートパイロットは、同じ応答契約とセッション状態を使用します。このハーネスは、実際のLinuxカーネル調査においてUSB gadget audioパスのstack out-of-bounds writeを発見するために使用され、その欠陥はCVE-2026-31720として公開されました。本実装は精密な静的解析ツールではなく、説明可能なヒューリスティックによってLLMの調査範囲を制限するリサーチワークフローであり、すべてのfindingはreachability、invariant break、concrete impactについて人間による再検証を要求します。

Index Terms— Linux kernel, vulnerability research, external signal, LLM orchestration, heuristic prioritization, syzbot, program analysis, Codex.

I. Introduction

Linuxカーネルのセキュリティレビューには、2種類の規模の問題があります。第一に、ソースツリー全体は1回のLLMコンテキストで扱うには大きすぎます。第二に、copy_from_user、アロケータ、refcount、lockなどのシグナルは一般的ですが、それ自体が脆弱性を意味するわけではありません。アナリストはまず「どこを見るか」を決定し、その後でuserspace reachabilityと具体的な状態遷移を別途証明する必要があります。

このプロジェクトの中核哲学はExternal Signalです。

LLMが自分でどこを見るかを決定させない。モデル推論の外部にある再現可能なシグナルが注意を配分するが、脆弱性の結論はreachabilityとinvariant evidenceによってのみ決定される。

したがって、ハーネスはモデルにカーネル全体を漠然と探索させません。ファイルを優先順位付けし、一度に1つの調査分岐のみを提供し、結論よりも証拠構造を先に要求します。

II. External Signal and Design Principles

A. External Signal Before Model Inference

External Signalは、LLMが生成した判断ではなく、モデル実行前に決定され、同じソースツリー・profile・保存されたsyzbot JSONから再計算できる観測値です。パス重み、正規表現ヒット、キャッシュされたsyzbot overlapがこれに該当します。このシグナルは候補のランクとプロンプトコンテキストにのみ使用され、verdictやproofに昇格させることはありません。

このドキュメントのExternal Signalはプロジェクト哲学全体を指します。コードのExternalSignalデータモデルは、現在そのうちsyzbot由来のシグナルのみを表現するため、2つの用語の範囲は異なります。

B. Prioritization Is Not Proof

正規表現ヒット、高リスクパス、syzbot overlapはすべて調査順序のためのシグナルです。スコアが高くても、実際の呼び出しパス、権限、カーネルconfig、namespace、デバイスの利用可能性が攻撃者の到達を許可しなければ、セキュリティfindingではありません。

C. Reachability Before Bug Class

監査は、syscall、ioctl、netlink、procfs、ファイルシステム、BPF、ドライバフックなど、userspaceから始まる境界を最初に確認します。その後で初めてUAF、OOB、refcount、race、info leak、capability checkなどのbug classを評価します。

D. One Investigation Branch at a Time

1つの調査単位は、基本的に1つのファイルと近接するcaller・teardown・free pathに制限されます。モデルが推奨するmanual follow-upは最大2回のみ許可されます。この制限は探索能力を減らすためではなく、検証可能な範囲内で結論を維持するためのものです。

E. 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が攻撃を防げない理由。

根拠が不十分な場合、モデルは脆弱性を強く主張する代わりに、次に確認する単一のターゲットを返します。これはprompt-level evidence contractであり、現在のパーサーが各証拠の完全性を自動検証するわけではありません。ingestionはverdictとnext targetを正規化するため、最終的な証拠検証は人間の責任です。

F. Design Lineage

初期の調査フローは、Protect AIのvulnhuntrが使用したファイル単位の分析、制限されたコンテキスト拡張、構造化された成果物という発想から出発しました [1]。このプロジェクトでは、これをPythonアプリケーション分析にそのまま適用せず、userspace-reachable kernel surface、カーネルオブジェクトのlifetime、teardown path、syzbot overlapを中心に再設計しました。特に優先順位シグナルと脆弱性証明を分離し、reachabilityをbug classより先に確認することがカーネルハーネスの中核的な設計選択です。

III. System Architecture

Fig. 1. The External Signal layer turns observations computed before model inference into ranked review units. It allocates attention but does not establish vulnerability proof.

TABLE I — MAJOR MODULE RESPONSIBILITIES

IV. Methodology

A. Candidate Discovery and Scoring

スキャナーはprofileのinclude directory以下の.cと.hファイルを走査します。ファイルfの優先順位スコアは概念的に次のように構成されます。

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

このスコアは確率やexploitabilityの尺度ではありません。各項目は、モデルが最初に確認するファイルを決めるための相対的な順序のみを提供します。現在の実装はすべてのline-level matchを合算し、プロンプトに表示する上位シグナルのみを制限します。同じ結果の再計算は、同じsource tree、profileとキャッシュされたsyzbot JSONを前提とします。syzbot weightはpath・lineヒューリスティックで先に候補となったファイルに事後適用され、syzbot hitだけで新しい候補ファイルを生成することはありません。

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

• ioctl、compat handler、file operation hook
• copy_from_user、copy_to_user、__user
• kmalloc、kzalloc、kvmalloc、キャッシュ割り当てとfree path
• refcount、atomic、kref演算
• size・length計算とmemcpy系
• lock、RCU、async lifetime関連パターン
• BPF、skb、XDP、netlink境界
• capabilityとnamespace check

B. Profile-Driven Scope

組み込みプロファイルはdefault、net、fs、io_uring、bpf、driversです。プロファイルはinclude path、pattern、weight、1つのファイルで保持するシグナル数を定義します。カーネル全体に1つのscoring policyを適用する代わりに、サブシステムごとの攻撃面とlifetime特性を反映します。

C. Crash Intelligence

syzbot-fetchはsyzkallerプロジェクトの公開syzbot bug page [2]からtitle、subsystem、bug type、file:line情報を抽出してJSONキャッシュに保存します。exact file overlapは強いExternal Signalとして、subsystem overlapは弱いExternal Signalとして使用します。live dashboardは変化する可能性があるため、再現単位はfetch時点の保存済みJSONです。クラッシュ情報はvariant huntingの出発点に過ぎず、新しい脆弱性の証拠として扱いません。

D. Session and Review Contract

scanはランク付けされたcandidate manifestと上位prompt bundleを生成します。各プロンプトはtarget path、score reason、line signal、syzbot contextと監査手順を含みます。

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

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

応答は1つのSingle best next targetと短いsummaryを含みます。pending targetのない古い応答は新しいターゲットに接続せず、別途archiveします。

V. Implementation and Usage

A. Requirements

• Python 3.11以上
• autopilot使用時はCodex CLI [3]と認証
• リモートsyzbot dashboard収集時はネットワーク接続

B. Installation

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

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

組み込みprofile JSONはwheelに含まれます。外部JSONルールは--config /path/to/profile.jsonで渡すことができます。

C. Minimal Workflow

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

# 2. Inspect high-priority candidates.
kernel-harness inspect artifacts/session-YYYYMMDDTHHMMSSZ --top 10

# 3. Render one focused prompt.
kernel-harness codex artifacts/session-YYYYMMDDTHHMMSSZ \
  --rank 1 \
  --include-snippet

--limitはmanifestに保持するcandidate数で、--topは最初に事前生成するprompt bundle数です。それ以降のrankのbundleも要求時に生成できます。

D. Time-Budgeted Autopilot

kernel-harness autopilot artifacts/session-YYYYMMDDTHHMMSSZ \
  --duration 30m \
  --per-run-timeout 10m \
  --include-snippet

デフォルトのsandboxはread-onlyです。分析過程でファイルの変更がどうしても必要な場合にのみ--sandbox workspace-writeを明示する必要があります。

E. Optional syzbot Feed

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

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              # present while a response is pending
├── bundles/
│   ├── <rank>-<target>.md
│   └── <rank>-<target>.snippet.txt
├── responses/
└── autopilot/
    ├── AUTOPILOT_STATUS.txt
    ├── AUTOPILOT_PROGRESS.txt
    ├── AUTOPILOT_FINDINGS.txt
    ├── prompts/
    ├── exec/
    └── findings/

VI. Operational Outcome and Verification

このバージョンは概念実証に留まらず、実際のLinuxカーネル脆弱性調査に使用されました。

TABLE II — DISCLOSED VULNERABILITY OUTCOME

検証は検出精度のベンチマークではなく、実装の回帰と配布可能性に焦点を当てます。

TABLE III — ENGINEERING VERIFICATION SCOPE

python -m unittest discover -s tests -v

GitHub Actionsはunit regressionを実行した後、wheelを新しい環境にインストールし、default profile scanをsmoke-testします。上記の公開事例は実際の調査で得られたoperational outcomeですが、代表的なLinux tree corpusで測定したprecision、recall、またはCVE discovery rate benchmarkではありません。

VII. Safety Considerations

• デフォルトのread-only sandboxを維持することを推奨します。
• 外部sandboxがない環境では--dangerously-bypass-approvals-and-sandboxを使用しないでください。
• 信頼できないsource commentとidentifierもモデル入力になり得るため、prompt injectionを考慮する必要があります。
• モデルが生成したfindingは、公開または報告前に人間がreachabilityとimpactを再検証する必要があります。
• syzbot crashと高いheuristic scoreを脆弱性の証明として引用してはなりません。

VIII. Limitations and Threats to Validity

1. Lexical analysis. 実際のC AST、call graph、interprocedural data flowを構築しません。
2. Score bias. コメント、マクロ、反復トークン、大きなファイルがスコアに過度な影響を与える可能性があります。
3. Reachability gap. カーネルconfig、privilege、namespace、デバイスの利用可能性を自動モデル化しません。
4. External data fragility. syzbot integrationは公開HTML構造の変更の影響を受けます。
5. Model dependence. 結果の品質は使用したモデル、prompt interpretation、repository contextに依存します。
6. Evaluation scope. 現在のテストはsoftware regressionを検証します。公開されたCVE事例は実際の使用結果ですが、セキュリティ検出性能に関する統計的評価を代替するものではありません。

IX. Retrospective

Git historyに記録された最初のバージョンから、目標は「LLMが脆弱性を自動的に見つけること」よりも「どのコードを最初に見て、どの証拠を要求するかを制御すること」に近いものでした。CVE-2026-31720を発見したv1-assisted調査は、狭いinvestigation unitとevidence contractが実際の研究に適用された事例を提供しました。v2はこのworkflowを、repository stateとknown referenceを一緒に保存するprovenance-aware triageまで拡張しました。今もう一度実装するなら、以下を優先します。

1. tree-sitterまたはClangベースのsymbol/call graph、
2. ファイルサイズと反復ヒットを考慮したscore normalization、
3. reviewとrunnerレイヤー分離によるCLI/autopilotの重複排除、
4. versioned manifestとatomic state write、
5. JSON Schemaベースのmodel responseとstructured evidence、
6. syzbot crash、fix commit、近傍variantの自動接続。

それでも維持したい中心原則はExternal Signalです。LLMにコードベース全体を漠然と探索させず、モデル外部のシグナルで絞り込んだ調査単位をreachabilityとinvariant中心で反復する。

X. Conclusion

Kernel Codex HarnessはLinuxカーネル脆弱性検出を代替しません。代わりにExternal Signalを説明可能なランクに変換し、LLMレビューを短く状態のある調査プロセスに制限します。この構造は実際の調査でCVE-2026-31720の発見に使用されました。プロジェクトの中核的な成果は新しい分析アルゴリズムを主張することではなく、LLMセキュリティレビューをexternal-signal attention allocation、evidence contract、reproducible orchestrationの問題として定義し、実戦的な研究ワークフローに適用したことにあります。

Appendix A. Repository Layout

.
├── .github/workflows/ci.yml
├── docs/
│   ├── assets/kernel-harness-architecture.svg
│   ├── AUTOPILOT.md
│   ├── CODEX_CLI.md
│   ├── CODEX_WORKFLOW.md
│   └── SYZBOT.md
├── kernel_harness/
│   ├── resources/
│   │   ├── linux-kernel-default.json
│   │   └── profiles/
│   ├── autopilot.py
│   ├── bundle.py
│   ├── cli.py
│   ├── ingest.py
│   ├── models.py
│   ├── prompting.py
│   ├── session.py
│   ├── syzbot.py
│   └── targeting.py
├── tests/test_regressions.py
├── README.md
└── pyproject.toml

詳細な運用手順はdocs/で確認できます。

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.