Kernel Codex Harness

한국어 | English

Research Tool · Original Import: 3 April 2026 · Documentation Revision: 11 July 2026

Core Philosophy — External Signal
Let reproducible observations outside model inference guide attention; never mistake priority for proof.

Project status. This repository preserves the initial version of an LLM-assisted research harness built and used for real Linux kernel vulnerability research. This version was used in the investigation that discovered the vulnerability published as CVE-2026-31720. The harness prioritizes investigation targets, but it does not automatically prove vulnerabilities or guarantee kernel security; final validation and reporting remain human responsibilities.

Abstract

Abstract— When an LLM is asked to explore a codebase as large as the Linux kernel without structure, its context quickly disperses and the presence of dangerous APIs is easily confused with actual exploitability. Kernel Codex Harness frames this challenge as a problem of investigation prioritization and stateful orchestration, rather than automatic vulnerability detection. The project calls its principle of controlling model attention with reproducible observations computed outside LLM inference External Signal. It combines kernel paths, userspace boundaries, static lifetime, usercopy, refcount, and size signals with optional syzbot crash intelligence to rank candidate files and turn each candidate into a narrow prompt bundle. Manual review and the time-budgeted autopilot share the same response contract and session state. The harness was used in a real Linux kernel investigation that discovered a stack out-of-bounds write in the USB gadget audio path, later published as CVE-2026-31720. This implementation is not a precise static analyzer; it is a research workflow that uses explainable heuristics to constrain the scope of LLM investigation, and every finding requires human revalidation of reachability, the invariant break, and concrete impact.

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

Module	Responsibility
targeting.py	Kernel file discovery and scoring of path, pattern, and syzbot signals
models.py	Data models for Candidate, Signal, and the syzbot-derived ExternalSignal
bundle.py	Manifest, session index, and prompt/snippet bundle generation
prompting.py	Kernel audit prompts centered on reachability and invariants
session.py	State for pending reviews, history, and follow-up depth
ingest.py	Normalization of strict verdicts and next targets
autopilot.py	Time-budgeted codex exec, logs, archives, and finding management
syzbot.py	Public syzbot page collection and local JSON cache generation
cli.py	Command routing for scan, inspect, codex, loop, and autopilot

IV. Methodology

A. Candidate Discovery and Scoring