Kernel Codex Harness v2

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

External Signal: From Attention Allocation to Provenance-Aware Triage
Use reproducible observations to guide model attention, then use repository provenance to organize review queues—never to claim proof.

Project Lineage— Kernel Codex Harness v1 · Attention Allocation → Kernel Codex Harness v2 · Provenance-Aware Triage

Project status. 이 저장소는 실제 Linux 커널 취약점 조사를 위해 v1의 attention-allocation workflow를 provenance-aware triage까지 발전시킨 LLM-assisted research harness입니다. 이 버전은 CVE-2026-53075로 공개된 취약점을 발견하는 데 사용됐습니다. 자동 취약점 탐지기, 신규성 판정기, exploit 검증기 또는 커널 보안 보증 도구가 아니며, 최종 검증과 보고는 사람이 수행합니다.

Abstract

Abstract— Linux 커널처럼 큰 코드베이스를 LLM에 그대로 탐색시키면 컨텍스트가 분산되고, 위험한 API의 존재와 실제 공격 가능성이 쉽게 혼동된다. Kernel Codex Harness v2는 이 문제를 두 단계의 External Signal 처리로 정의한다. 모델 호출 전에는 경로 weight, lexical hit, cached 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

커널 보안 검토에는 서로 다른 두 종류의 불확실성이 있다.

어디를 먼저 볼 것인가. 전체 소스 트리는 한 번의 모델 컨텍스트로 다루기에 너무 크다.
모델이 낸 강한 finding을 어떻게 취급할 것인가. 로컬 수정, 기존 fix, 알려진 CVE 또는 불완전한 repository state가 결론을 오염시킬 수 있다.

v1의 중심 문제는 첫 번째, 즉 attention allocation이었다. v2는 그 원칙을 유지하면서 두 번째 문제를 provenance-aware triage로 확장한다. 두 버전은 각각 실제 조사에 사용됐으며, v1-assisted investigation은 CVE-2026-31720으로, v2-assisted investigation은 CVE-2026-53075로 이어졌다.

모델 바깥의 관찰값으로 조사 범위를 좁히고, 모델 응답 뒤에는 검증 가능한 repository 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, cached syzbot JSON을 사용하면 candidate rank를 다시 계산할 수 있다. 이 점수는 확률이나 exploitability가 아니라 어디를 먼저 볼지 정하는 상대적 순서다.

B. Stage 2 — Provenance-Aware Triage After Inference

Post-inference 단계는 strong model verdict에 다음 정보를 결합한다.

Git repository 여부와 status 수집 성공 여부
branch와 HEAD
repository 및 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는 두 종류의 입력을 결합하되 그 출처를 구분해 기록한다.

C. Heuristic Buckets, Not Novelty Proof

Strong finding은 운영상 다음 review bucket 중 하나로 정리된다.

Bucket	Meaning
`new_candidate`	provenance가 확인되고 dirty/known blocking signal이 발견되지 않은 후보
`known_issue`	non-negated known reference 또는 응답이 fix/upstream 관계로 지목하고 현재 HEAD에 포함된 commit이 확인된 후보
`dirty_tree_suspect`	dirty repository 또는 dirty target의 영향을 배제할 수 없는 후보
`provenance_unknown`	Git repository, status 또는 HEAD를 신뢰성 있게 확인하지 못한 후보

모든 분류 결과의 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

한 조사 단위는 하나의 파일과 가까운 caller·teardown·free path로 제한한다. 모델이 제안하는 manual follow-up은 최대 두 번으로 제한해 broad exploration보다 검증 가능한 짧은 경로를 유지한다.

F. Evidence Over Confidence

강한 finding은 최소한 다음을 설명해야 한다.

attacker-reachable entrypoint,
attacker-controlled field 또는 lifetime transition,
깨지는 object·length·state invariant,
corruption, leak, privilege escalation 등 구체적인 impact,
기존 check가 공격을 막지 못하는 이유.

Parser는 verdict와 next target을 정규화할 뿐 이 증거의 완결성을 자동 증명하지 않는다.

G. Design Lineage

초기 흐름은 Protect AI의 vulnhuntr가 사용한 파일 단위 분석, 제한된 컨텍스트 확장, 구조화된 결과물이라는 발상에서 출발했다 [1]. 이 프로젝트에서는 이를 userspace-reachable kernel surface, 커널 객체 lifetime, teardown path, syzbot overlap에 맞게 다시 설계했다. v2의 추가 기여는 attention allocation 뒤에 repository provenance를 이용한 finding triage 단계를 둔 것이다.

III. System Architecture

Two-stage External Signal architecture for Kernel Codex Harness v2

Fig. 1. Pre-inference External Signal ranks reproducible review units. Post-inference triage combines model-independent Git provenance with model-derived response references, without treating the latter as External Signal or authoritative fact. Human validation remains outside both automated stages.

TABLE I — MAJOR MODULE RESPONSIBILITIES

Module	Responsibility
`targeting.py`	커널 파일 탐색과 path·lexical·syzbot 신호 점수화
`models.py`	`Candidate`, `Signal`, syzbot-derived `ExternalSignal`
`bundle.py`	manifest, session index, prompt/snippet bundle 생성
`prompting.py`	reachability와 invariant 중심의 커널 감사 프롬프트
`session.py`	pending review, history, follow-up depth 상태 저장
`ingest.py`	strict verdict와 single next target 정규화
`repo_state.py`	Git branch, HEAD, status, dirty path, ancestry 수집
`finding_triage.py`	provenance와 known-reference 기반 heuristic bucket 분류
`autopilot.py`	시간 예산 기반 Codex 실행, ingest, archive, finding 기록
`syzbot.py`	공개 syzbot HTML 수집과 로컬 JSON cache 생성
`cli.py`	scan/review/doctor/autopilot 명령 연결

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

Profile	Focus
`default`	kernel/mm/net/fs/security/io_uring/lib/drivers 시작점
`net`	netlink, socket, skb, XDP
`fs`	ioctl, procfs, seq_file, debugfs
`io_uring`	async request lifetime과 teardown
`bpf`	verifier, map/program lifetime, BTF
`drivers`	ioctl, DMA, MMIO와 driver teardown

linux-kernel-codex-harness-v2

인기