Abstract— Wenn man LLMs eine so große Codebasis wie den Linux-Kernel direkt durchsuchen lässt, wird der Kontext zerstreut und die Existenz gefährlicher APIs wird leicht mit tatsächlicher Ausnutzbarkeit verwechselt. Kernel Codex Harness v2 definiert dieses Problem als zweistufige Externe-Signal-Verarbeitung. Vor dem Modellaufruf werden Kandidatendateien anhand von Pfadgewichten, lexikalischen Treffern und gecachtem syzbot-Overlap priorisiert, um die Aufmerksamkeit zu verteilen. Nach der Modellantwort werden Git-Branch, HEAD und Dirty-State mit aus der Antwort extrahierten CVE-, Commit- und bekannten Markern kombiniert, um starke Befunde in Provenienz-bewusste Review-Buckets zu klassifizieren. Dieser Harness wurde in einer realen Linux-Kernel-Untersuchung verwendet, um einen Validierungsfehler der Ziel-Netzwerk-Namespace-Berechtigung von PPP zu finden, der als CVE-2026-53075 veröffentlicht wurde. Triage ist eine Heuristik zur Organisation von Untersuchungswarteschlangen; insbesondere bedeutet new_candidate nur, dass keine bekannten Hinweise oder Provenienzprobleme gefunden wurden, nicht einen Neuheitsbeweis. Alle Befunde erfordern eine menschliche Revalidierung von Userspace-Erreichbarkeit, Invariantenbruch und konkreter Auswirkung.

Indexbegriffe— Linux-Kernel, Schwachstellenforschung, externes Signal, Provenienz, heuristisches Triage, LLM-Orchestrierung, syzbot, Codex.

I. Einleitung

Die Sicherheitsüberprüfung des Kernels umfasst zwei verschiedene Arten von Unsicherheit.

1. Wo man zuerst hinschauen sollte. Der gesamte Quellbaum ist zu groß, um in einem einzigen Modellkontext behandelt zu werden.
2. Wie man mit starken Befunden des Modells umgeht. Lokale Änderungen, bestehende Fixes, bekannte CVEs oder ein unvollständiger Repository-Zustand können die Schlussfolgerungen verfälschen.

Das zentrale Problem von v1 war das erste, nämlich die Aufmerksamkeitsverteilung. v2 behält dieses Prinzip bei und erweitert das zweite Problem um ein Provenienz-bewusstes Triage. Beide Versionen wurden jeweils in realen Untersuchungen eingesetzt; die v1-gestützte Untersuchung führte zu CVE-2026-31720, die v2-gestützte Untersuchung zu CVE-2026-53075.

Beobachtungen außerhalb des Modells grenzen den Untersuchungsumfang ein, und nach der Modellantwort wird eine verifizierbare Repository-Provenienz hinzugefügt. Kein Signal in irgendeiner Phase beweist eine Schwachstelle oder Neuheit.

II. Externes Signal und Designprinzipien

A. Stufe 1 — Aufmerksamkeitsverteilung vor der Inferenz

Pre-Inferenz-Externe-Signale sind Beobachtungen, die vor der Modellausführung berechnet werden, nicht LLM-Urteile.

• Kernel-Pfade und Subsystem-Gewichte
• Lexikalische Treffer wie usercopy, allocator, refcount, size, lock
• Datei-/Subsystem-Overlap aus gespeicherten syzbot-JSON-Daten

Mit demselben Quellbaum, Profil und gecachten syzbot-JSON-Daten kann das Kandidaten-Ranking neu berechnet werden. Diese Punktzahl ist keine Wahrscheinlichkeit oder Ausnutzbarkeit, sondern eine relative Reihenfolge, wo man zuerst hinschauen sollte.

B. Stufe 2 — Provenienz-bewusstes Triage nach der Inferenz

Die Post-Inferenz-Phase kombiniert ein starkes Modellurteil mit den folgenden Informationen.

• Ob es sich um ein Git-Repository handelt und ob die Status-Erfassung erfolgreich war
• Branch und HEAD
• Dirty-State des Repositorys und der Zieldatei
• Aus der Antwort extrahierte CVE-, Commit-Hash- und bekannte Issue-Marker
• In der Antwort erscheinende Negations- oder Nicht-verwandte-Referenz-Ausdrücke

In diesem Dokument bezieht sich Post-Inferenz-Externes Signal nur auf Provenienz, die unabhängig vom Modell gesammelt wurde, wie Git-Repository/Status, Branch, HEAD, Dirty-State und lokale Commit-Abstammung. CVE-, Commit- und bekannte Marker sind modellabgeleitete Referenzen, die aus der Modellantwort extrahiert wurden, und kein externes Signal oder autoritative Tatsache. Triage kombiniert beide Arten von Eingaben, zeichnet aber deren Quellen getrennt auf.

C. Heuristische Buckets, kein Neuheitsbeweis

Starke Befunde werden betrieblich in einen der folgenden Review-Buckets eingeordnet.

novelty_proven ist für alle Klassifizierungsergebnisse false. new_candidate bedeutet nicht „neue Schwachstelle“, sondern eine Warteschlange, in der Menschen zuerst die Neuheitsuntersuchung fortsetzen sollten.

D. Erreichbarkeit vor Bug-Klasse

Die Prüfung identifiziert zuerst Grenzen, die vom Userspace ausgehen, wie syscall, ioctl, netlink, procfs, Dateisystem, BPF und Driver-Hooks. Erst danach werden Bug-Klassen wie UAF, OOB, refcount, race, info leak und capability check bewertet.

E. Ein Untersuchungszweig nach dem anderen

Eine Untersuchungseinheit ist auf eine Datei und deren nahe Caller-, Teardown- und Free-Pfade beschränkt. Manuelle Follow-ups, die das Modell vorschlägt, sind auf maximal zwei begrenzt, um einen verifizierbaren kurzen Pfad statt einer breiten Erkundung beizubehalten.

F. Beweise vor Vertrauen

Ein starker Befund muss mindestens Folgendes erklären.

1. einen für Angreifer erreichbaren Entrypoint,
2. ein angreiferkontrolliertes Feld oder einen Lifetime-Übergang,
3. eine gebrochene Objekt-, Längen- oder Zustandsinvariante,
4. eine konkrete Auswirkung wie Korruption, Leck oder Privilegieneskalation,
5. warum bestehende Checks den Angriff nicht verhindern.

Der Parser normalisiert nur Urteil und nächstes Ziel; er beweist nicht automatisch die Vollständigkeit dieser Beweise.

G. Design-Abstammung

Der anfängliche Ablauf stammt aus der Idee der dateibasierten Analyse, des begrenzten Kontexterweiterung und der strukturierten Ergebnisse, die Protect AIs vulnhuntr verwendet [1]. In diesem Projekt wurde dies für die userspace-erreichbare Kernel-Oberfläche, die Kernel-Objekt-Lebensdauer, Teardown-Pfade und syzbot-Overlap neu gestaltet. Der zusätzliche Beitrag von v2 ist die Platzierung einer Finding-Triage-Stufe auf Basis der Repository-Provenienz nach der Aufmerksamkeitsverteilung.

III. Systemarchitektur

Abb. 1. Pre-Inferenz-Externe-Signale ordnen reproduzierbare Untersuchungseinheiten. Post-Inferenz-Triage kombiniert modellunabhängige Git-Provenienz mit modellabgeleiteten Antwortreferenzen, ohne letztere als externes Signal oder autoritative Tatsache zu behandeln. Die menschliche Validierung bleibt außerhalb beider automatisierter Stufen.

TABELLE I — HAUPTMODULVERANTWORTLICHKEITEN

IV. Methodik

A. Kandidatenfindung und Bewertung

Der Scanner durchläuft .c- und .h-Dateien unter den Include-Verzeichnissen des Profils.

Die aktuelle Implementierung summiert Zeilenebenen-Treffer und begrenzt nur die Anzahl der Top-Signale, die im Prompt angezeigt werden. Die Punktzahl bestimmt die Untersuchungsreihenfolge des Modells, ist aber kein statistischer Wert, der die Schwachstellenwahrscheinlichkeit kalibriert.

Die wichtigsten statischen Signale sind:

• ioctl, compat handler, Dateioperationen-Hooks
• copy_from/to_user und __user
• kmalloc/kzalloc/kvmalloc, Cache-Allokation und Free-Pfade
• refcount, atomic, kref
• Größen-/Längenberechnungen und memcpy-Familien
• lock, RCU, asynchrone Lebensdauer
• BPF, skb, XDP, netlink
• Capability- und Namespace-Checks

B. Profilgesteuerter Umfang

C. Crash-Intelligenz

syzbot-fetch extrahiert Titel, Subsystem, Bug-Typ und Datei:Zeile aus öffentlichen syzbot-Bug-Seiten und speichert sie als JSON. Exakter Datei-Overlap ist ein starkes Ranking-Signal, Subsystem-Overlap ein schwaches Signal. Da das Live-Dashboard variieren kann, ist die reproduzierbare Einheit das zum Abrufzeitpunkt gespeicherte JSON. Crash-Overlap ist ein Hinweis für die Variantenjagd, kein Schwachstellenbeweis.

D. Sitzungs- und Review-Vertrag

scan erstellt ein vollständiges, sortiertes Kandidaten-Manifest und ein Top-Prompt-Bundle. --limit ist die Anzahl der Kandidaten, die im Manifest verbleiben, und --top die Anzahl der vorab erstellten Bundles. Weitere Ränge können bei Bedarf erstellt werden.

Die Modellantwort wird in eines der folgenden Urteile normalisiert.

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

Manuelles Review und Autopilot verwenden dieselbe review_state.json, denselben festen Antwortpfad und denselben Urteils-Parser.

E. Provenienzerfassung und Triage

doctor und Autopilot prüfen, ob ein Git-Repository vorhanden ist, ob die Status-Erfassung erfolgreich war, sowie Branch, HEAD und Dirty-Pfade. Zustände, in denen die Provenienz nicht bestätigt werden kann, werden nicht als sauber betrachtet, sondern als provenance_unknown beibehalten.

Das Triage starker Urteile folgt ungefähr der folgenden Priorität.

1. Wenn die Provenienz nicht vertrauenswürdig ist, dann provenance_unknown,
2. Wenn das Repository oder Ziel dirty ist, dann dirty_tree_suspect,
3. Wenn eine verwandte CVE oder ein nicht-negierter Marker vorhanden ist oder ein Commit, das die Antwort als Fix/Upstream-Beziehung identifiziert, ein Vorfahre des aktuellen HEAD ist, dann known_issue,
4. Andernfalls new_candidate.

Negations- oder Nicht-verwandte-Ausdrücke wie „kein bekanntes Problem“ oder „nicht verwandt mit CVE-…“ werden nicht als bekannte Grundlage verwendet. Die endgültige Entscheidung enthält zusammen mit dem ursprünglichen Urteil Branch, HEAD, Status, Dirty-State, übereinstimmende Referenz und Grund.

Die aktuelle Provenienz-bewusste Bucket-Klassifizierung und der JSONL-Writer werden auf den Autopilot-Ingest-Pfad angewendet. Manuelle loop- und ingest-Befehle verwenden denselben zugrunde liegenden Sitzungszustand und Urteils-Parser, erstellen jedoch keine Bucket-Artefakte.

V. Implementierung und Verwendung

A. Anforderungen

• Python 3.11 oder höher
• Linux-Kernel-Quellbaum
• Git für die Verwendung von provenance/doctor/autopilot
• Codex CLI und Authentifizierung für die Verwendung von autopilot [3]
• Netzwerkverbindung für die Remote-syzbot-Erfassung

Die Python-Laufzeitabhängigkeiten umfassen nur die Standardbibliothek.

B. Installation

Die integrierten Profil-JSON-Dateien sind im Wheel enthalten. Zusätzliche Regeln können mit --config /path/to/profile.json übergeben werden.

C. Minimaler Workflow

Manuelle Codex-Antworten werden in der vom Runbook festgelegten Datei codex_response.txt gespeichert und können dann mit dem folgenden Befehl übernommen werden.

D. Zeitbudgetierter Autopilot

Der Codex-Sandbox-Standardwert ist read-only. --require-clean-tree erlaubt die Ausführung nur, wenn Git-Repository, Status und HEAD bestätigt sind und der Arbeitsbaum sauber ist. --stop-on-finding stoppt nur, wenn das heuristische Triage-Ergebnis new_candidate ist.

E. Optionaler syzbot-Feed

F. Sitzungsartefakte

AUTOPILOT_FINDINGS.jsonl bewahrt Urteil, Bucket, Grund, Branch, HEAD, Provenienzstatus, übereinstimmende Referenz sowie Finding-/Archivpfade in einer nachverarbeitbaren Form.

VI. Betriebsergebnis und Verifizierung

v2 wurde mit der erweiterten Struktur auf eine reale Linux-Kernel-Schwachstellenuntersuchung angewendet.

TABELLE II — VERÖFFENTLICHTES SCHWACHSTELLENERGEBNIS

Die 16 Regressionstests konzentrieren sich nicht auf einen Benchmark zur Genauigkeit der Sicherheitserkennung, sondern auf Softwareverträge und Bereitstellbarkeit.

• Allocator- und integrierte Profilressourcen-Regressionen
• Sicherstellung, dass negative Urteile und CVE-Ausdrücke in allgemeiner Prosa nicht zu starken Befunden umgekehrt werden
• Begrenzung manueller Follow-ups und Rangfolge
• Archivierung veralteter Antworten ohne ausstehende Ziele
• Read-only-Sandbox-Standardwert und positive CLI-Argumente
• Fail-closed-Provenienz bei fehlendem/Nicht-Git/Statusfehler
• Triage von Dirty-Zielen, bekannten Referenzen, Negation und nicht verwandten CVEs
• Sitzungsverlauf und JSONL-Erhaltung von Klassifizierungsmetadaten
• Parse-Fehler- und Finding-Artefaktverträge
• Profil-Scan-Smoke-Test aus installiertem Wheel

GitHub Actions führt Regressionstests unter Python 3.11 und 3.12 aus, installiert das Wheel und führt einen Smoke-Test der 6 paketierten Profile und des Standard-Scans durch. Das obige öffentliche Beispiel ist ein betriebliches Ergebnis aus einer realen Untersuchung, aber kein Benchmark für Precision, Recall, Ausnutzbarkeit oder CVE-Entdeckungsrate, gemessen an einem repräsentativen Linux-Baum-Korpus.

VII. Sicherheitshinweise

• Der Codex-Sandbox-Standardwert ist read-only und es wird empfohlen, ihn beizubehalten.
• Wenn saubere Provenienz wichtig ist, verwenden Sie nach doctor die Option --require-clean-tree.
• Interpretieren Sie Nicht-Git- oder Status-/HEAD-Erfassungsfehler nicht als sauber.
• --dangerously-bypass-approvals-and-sandbox sollte nur in isolierten Experimentierumgebungen verwendet werden.
• Da Quellkommentare und Bezeichner ebenfalls Modelleingaben sind, berücksichtigen Sie die Möglichkeit von Prompt-Injection.
• CVE- und Commit-Strings sind nur Antwortreferenzen, keine autoritativen Bestätigungen.
• Vor der Offenlegung oder Berichterstattung eines Befunds müssen Menschen Erreichbarkeit, Invariante, Auswirkung und betroffene Version erneut validieren.

VIII. Einschränkungen und Gültigkeitsbedrohungen

1. Lexikalische Analyse. Es wird kein echter C-AST, Call-Graph oder interprozeduraler Datenfluss erstellt.
2. Punktzahlverzerrung. Kommentare, Makros, wiederholte Token und große Dateien können die Punktzahl übermäßig beeinflussen.
3. Erreichbarkeitslücke. Kernel-Konfiguration, Privilegien, Namespaces und Geräteverfügbarkeit werden nicht automatisch modelliert.
4. Fragilität externer Daten. Die syzbot-Integration ist von Änderungen an der öffentlichen HTML-Struktur betroffen.
5. Nur lokale Provenienz. Die Git-Abstammung basiert auf dem HEAD des aktuellen Checkouts und repräsentiert nicht die gesamte Upstream- und Vendor-Historie.
6. Antwortabgeleitete Referenzen. CVE- und bekannte Marker werden aus der Modellantwort extrahiert, daher sind Auslassungen, Halluzinationen und Kontextmissverständnisse möglich.
7. Heuristisches Triage. Sowohl new_candidate als auch known_issue sind keine endgültigen Neuheitsurteile.
8. Modellabhängigkeit. Die Ergebnisqualität hängt vom Modell, der Prompt-Interpretation und dem verfügbaren Repository-Kontext ab.
9. Bewertungsumfang. Die aktuellen Tests verifizieren Software-Regressionen. Das veröffentlichte CVE-Beispiel ist ein reales Nutzungsergebnis, ersetzt jedoch keine statistische Bewertung der Sicherheitserkennungsleistung.

IX. Entwicklung und Retrospektive

v1 (Repository) konzentrierte sich auf das Problem der Verteilung der LLM-Aufmerksamkeit durch externe Signale und wurde in einer realen v1-gestützten Untersuchung verwendet, um CVE-2026-31720 zu finden. v2 führt dieselbe Forschungshilosophie fort und erweitert sie so, dass auch nach einem starken Befund des Modells Repository-Zustand und antwortabgeleitete Referenzen gemeinsam protokolliert werden. In einer Folgeuntersuchung mit dieser Struktur wurde CVE-2026-53075 gefunden.

Zwei Prinzipien dieser Entwicklung müssen beibehalten werden.

1. Pre-Inferenz-Punktzahlen nicht als Schwachstellenbeweis missverstehen.
2. Post-Inferenz-Buckets nicht als Neuheitsbeweis missverstehen.

Wenn man es jetzt erneut erweitern würde, hätten Clang-/tree-sitter-Call-Graphen, Punktzahl-Normalisierung, versionierte Manifeste mit Interprozess-Zustandssperrung, autoritative CVE-/Fix-Datenbank-Adapter sowie die Trennung von Runner, Triage und Artefakt-Schreiber Priorität. Der aktuelle Zustandsschreibvorgang selbst verwendet temporäre Dateien und atomares Ersetzen.

X. Fazit

Kernel Codex Harness v2 ersetzt keine Schwachstellenerkennung. Vor dem Modellaufruf verteilen externe Signale das Untersuchungsbudget auf erklärbare Kandidaten; nach dem Modellaufruf organisieren Provenienzsignale starke Befunde in überprüfbare Warteschlangen. Diese Struktur wurde in einer realen Untersuchung zur Entdeckung von CVE-2026-53075 verwendet. Das Kernresultat des Projekts ist kein Algorithmus zur automatischen Neuheitsbestimmung, sondern ein praxiserprobter LLM-Sicherheitsreview-Workflow, der Aufmerksamkeitsverteilung und Provenienz-bewusstes Triage explizit trennt.

Anhang A. Repository-Struktur

Detaillierte manuelle Betriebsabläufe finden Sie im Codex-CLI-Leitfaden, automatische Ausführung und Triage im Autopilot-Leitfaden und Crash-Intelligenz im syzbot-Leitfaden.

Referenzen

[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/

Lizenz

Lizenziert unter der Apache License 2.0.