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

I. Introduction

Linux kernel security review has two distinct scale problems. First, the full source tree is too large for a single LLM context. Second, signals such as copy_from_user, allocators, refcounts, and locks are common, but do not by themselves imply a vulnerability. An analyst must first decide where to look, then separately prove userspace reachability and the concrete state transition.

The core philosophy of this project is External Signal.

Do not let the LLM decide where to look on its own. Reproducible signals outside model inference allocate attention, while vulnerability conclusions are determined only by reachability and invariant evidence.

The harness therefore does not ask the model to wander broadly across the entire kernel. It prioritizes files, presents one investigation branch at a time, and requires an evidence structure before a conclusion.

II. External Signal and Design Principles

A. External Signal Before Model Inference

External Signal is not a judgment generated by an LLM. It is an observation determined before model execution and reproducible from the same source tree, profile, and stored syzbot JSON. Path weights, regular-expression hits, and cached syzbot overlap are examples. These signals affect only candidate ranking and prompt context; they are never promoted to a verdict or proof.

In this document, External Signal names the overall project philosophy. The ExternalSignal data model in the code currently represents only the syzbot-derived subset, so the two terms have different scopes.

B. Prioritization Is Not Proof

Regular-expression hits, high-risk paths, and syzbot overlap are all signals for ordering an investigation. A high score is not a security finding when the actual call path, privileges, kernel configuration, namespace, or device availability does not permit attacker reachability.

C. Reachability Before Bug Class

The audit first identifies boundaries that originate in userspace, such as a syscall, ioctl, netlink, procfs, filesystem, BPF, or driver hook. Only then does it evaluate bug classes such as UAF, OOB access, refcount errors, races, information leaks, or capability-check failures.

D. One Investigation Branch at a Time

An investigation unit is normally limited to one file and its nearby caller, teardown, and free paths. At most two model-recommended manual follow-ups are allowed. This limit is not intended to reduce exploration capability, but to keep conclusions within a verifiable scope.

E. Evidence Over Confidence

The prompt requires a strong finding to explain at least the following:

1. attacker-reachable entrypoint,
2. an attacker-controlled field or lifetime transition,
3. the object, length, or state invariant that breaks,
4. a concrete impact such as corruption, leakage, or privilege escalation,
5. why existing checks do not block the attack.

When evidence is insufficient, the model returns one next target to inspect instead of making a strong vulnerability claim. This is a prompt-level evidence contract; the current parser does not automatically prove the completeness of every evidence field. Ingestion normalizes the verdict and next target, so final evidence validation remains a human responsibility.

F. Design Lineage

The initial investigation flow drew inspiration from the file-level analysis, bounded context expansion, and structured outputs used by Protect AI's vulnhuntr [1]. Rather than applying that Python application workflow unchanged, this project redesigned it around userspace-reachable kernel surfaces, kernel object lifetimes, teardown paths, and syzbot overlap. In particular, separating prioritization signals from vulnerability proof and checking reachability before bug class is the kernel harness's central design choice.

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

The scanner walks .c and .h files under the profile's include directories. Conceptually, the priority score for file f is composed as follows.

This score is neither a probability nor an exploitability metric. Its components provide only a relative order for deciding which files the model should inspect first. The current implementation sums all line-level matches and limits only the highest-ranked signals displayed in the prompt. Reproducing the same result assumes the same source tree, profile, and cached syzbot JSON. A syzbot weight is applied after path and line heuristics have already made a file a candidate; a syzbot hit alone does not create a new candidate file.

The main static signals are:

• ioctl, compat handler, file operation hook
• copy_from_user, copy_to_user, __user
• kmalloc, kzalloc, kvmalloc, cache allocation, and free paths
• refcount, atomic, and kref operations
• size and length calculations and the memcpy family
• lock, RCU, and asynchronous lifetime patterns
• BPF, skb, XDP, and netlink boundaries
• capability and namespace checks

B. Profile-Driven Scope

The built-in profiles are default, net, fs, io_uring, bpf, and drivers. A profile defines include paths, patterns, weights, and the number of signals retained per file. Rather than applying one scoring policy to the entire kernel, profiles reflect subsystem-specific attack surfaces and lifetime characteristics.

C. Crash Intelligence

syzbot-fetch extracts titles, subsystems, bug types, and file:line information from public syzbot bug pages in the syzkaller project [2] and stores them in a JSON cache. Exact file overlap is used as a strong External Signal, while subsystem overlap is a weaker one. Because the live dashboard can change, the unit of reproducibility is the JSON captured at fetch time. Crash information is a starting point for variant hunting, not evidence of a new vulnerability.

D. Session and Review Contract

scan creates a ranked candidate manifest and prompt bundles for the highest-ranked targets. Each prompt includes the target path, scoring rationale, line signals, syzbot context, and audit procedure.

Model responses are normalized to one of the following verdicts:

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

A response includes one Single best next target and a short summary. A stale response without a pending target is archived separately rather than attached to a new target.

V. Implementation and Usage

A. Requirements

• Python 3.11 or later
• Codex CLI [3] and authentication when using the autopilot
• Network access when collecting a remote syzbot dashboard

B. Installation

Built-in profile JSON files are included in the wheel. External JSON rules can be supplied with --config /path/to/profile.json.

C. Minimal Workflow

--limit is the number of candidates retained in the manifest, while --top is the number of prompt bundles pre-generated initially. Bundles for later ranks can be generated on demand.

D. Time-Budgeted Autopilot

The default sandbox is read-only. Specify --sandbox workspace-write only when file modification is strictly necessary during analysis.

E. Optional syzbot Feed

F. Session Artifacts

VI. Operational Outcome and Verification

This version went beyond a proof of concept and was used in a real Linux kernel vulnerability investigation.

TABLE II — DISCLOSED VULNERABILITY OUTCOME

Verification focuses on implementation regressions and distributability, not a detection-accuracy benchmark.

TABLE III — ENGINEERING VERIFICATION SCOPE

GitHub Actions runs unit regressions, installs the wheel into a fresh environment, and smoke-tests a default profile scan. The public case above is an operational outcome from real research, not a precision, recall, or CVE discovery-rate benchmark measured on a representative Linux tree corpus.

VII. Safety Considerations

• Keep the default read-only sandbox.
• Do not use --dangerously-bypass-approvals-and-sandbox without an external sandbox.
• Treat untrusted source comments and identifiers as model inputs and account for prompt injection.
• A human must revalidate the reachability and impact of every model-generated finding before disclosure or reporting.
• Do not cite a syzbot crash or a high heuristic score as vulnerability proof.

VIII. Limitations and Threats to Validity

1. Lexical analysis. The harness does not build a real C AST, call graph, or interprocedural data flow.
2. Score bias. Comments, macros, repeated tokens, and large files can disproportionately influence scores.
3. Reachability gap. Kernel configuration, privileges, namespaces, and device availability are not modeled automatically.
4. External data fragility. The syzbot integration is sensitive to changes in the public HTML structure.
5. Model dependence. Result quality depends on the model, prompt interpretation, and repository context.
6. Evaluation scope. Current tests verify software regressions. The disclosed CVE case is a real operational outcome, but does not replace a statistical evaluation of vulnerability-detection performance.

IX. Retrospective

From the earliest version recorded in Git history, the goal was closer to controlling which code an LLM should inspect first and what evidence it must provide than to having the LLM find vulnerabilities on its own. The v1-assisted investigation that discovered CVE-2026-31720 demonstrated how a narrow investigation unit and evidence contract could be applied in real research. v2 extended this workflow into provenance-aware triage that preserves repository state and known references together. A new implementation would prioritize:

1. a tree-sitter- or Clang-based symbol/call graph,
2. score normalization that accounts for file size and repeated hits,
3. separation of review and runner layers to eliminate CLI/autopilot duplication,
4. versioned manifests and atomic state writes,
5. JSON Schema-based model responses and structured evidence,
6. automatic linkage of syzbot crashes, fix commits, and nearby variants.

The central principle worth retaining is still External Signal: do not ask an LLM to explore an entire codebase vaguely; use signals outside the model to narrow the investigation unit, then iterate around reachability and invariants.

X. Conclusion

Kernel Codex Harness does not replace Linux kernel vulnerability detection. Instead, it turns External Signal into an explainable ranking and constrains LLM review to a short, stateful investigation process. This structure was used in the real investigation that discovered CVE-2026-31720. The project's central result is not a claim of a new analysis algorithm, but the definition and practical application of LLM security review as a problem of external-signal attention allocation, evidence contracts, and reproducible orchestration.

Appendix A. Repository Layout

Detailed operating procedures are available in 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.