Index Terms— Linux-Kernel, Schwachstellenforschung, externes Signal, LLM-Orchestrierung, heuristische Priorisierung, syzbot, Programmanalyse, Codex.

I. Einleitung

Die Sicherheitsprüfung des Linux-Kernels hat zwei Arten von Skalierungsproblemen. Erstens ist der gesamte Quellbaum zu groß für einen einzigen LLM-Kontext. Zweitens sind Signale wie copy_from_user, Allokatoren, Refcounts und Locks häufig, bedeuten aber für sich genommen keine Schwachstelle. Der Analyst muss zuerst entscheiden, „wo gesucht werden soll“, und dann Userspace-Erreichbarkeit und konkrete Zustandsübergänge separat beweisen.

Die Kernphilosophie dieses Projekts ist External Signal.

Das LLM entscheidet nicht selbst, wo es hinsieht. Reproduzierbare Signale außerhalb der Modellinferenz verteilen die Aufmerksamkeit, aber Schwachstellenschlussfolgerungen werden nur durch Erreichbarkeits- und Invariantenevidenz bestimmt.

Daher lässt der Harness das Modell nicht vage den gesamten Kernel durchsuchen. Er priorisiert Dateien, bietet jeweils nur einen Untersuchungszweig an und verlangt zuerst Beweisstrukturen statt Schlussfolgerungen.

II. External Signal und Designprinzipien

A. External Signal vor der Modellinferenz

External Signal ist kein vom LLM generiertes Urteil, sondern eine Beobachtung, die vor der Modellausführung bestimmt und aus demselben Quellbaum, Profil und gespeicherten syzbot-JSON neu berechnet werden kann. Pfadgewichte, Regex-Treffer und gecachte syzbot-Überlappungen fallen darunter. Diese Signale werden nur für Kandidatenranking und Prompt-Kontext verwendet und nicht zu Urteilen oder Beweisen erhoben.

External Signal in diesem Dokument bezieht sich auf die gesamte Projektphilosophie. Das ExternalSignal-Datenmodell im Code repräsentiert derzeit nur die daraus abgeleiteten syzbot-Signale, daher unterscheidet sich der Umfang der beiden Begriffe.

B. Priorisierung ist kein Beweis

Regex-Treffer, Hochrisikopfade und syzbot-Überlappungen sind allesamt Signale für die Untersuchungsreihenfolge. Eine hohe Punktzahl ist kein Sicherheitsfinding, wenn der tatsächliche Aufrufpfad, Berechtigungen, Kernel-Konfiguration, Namespace oder die Geräteverfügbarkeit dem Angreifer keinen Zugriff ermöglichen.

C. Erreichbarkeit vor Bug-Klasse

Die Prüfung identifiziert zuerst Grenzen, die vom Userspace ausgehen, wie syscall, ioctl, netlink, procfs, Dateisysteme, BPF und Driver-Hooks. Erst danach werden Bug-Klassen wie UAF, OOB, Refcount, Race, Info-Leak und Capability-Checks bewertet.

D. Ein Untersuchungszweig nach dem anderen

Eine Untersuchungseinheit ist standardmäßig auf eine Datei und nahe Caller-, Teardown- und Free-Pfade beschränkt. Vom Modell empfohlene manuelle Folgeuntersuchungen sind auf maximal zwei beschränkt. Diese Einschränkung soll nicht die Explorationsfähigkeit verringern, sondern Schlussfolgerungen innerhalb eines verifizierbaren Rahmens halten.

E. Evidenz vor Zuversicht

Die Prompts verlangen, dass ein starkes Finding mindestens die folgenden Punkte erklärt:

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

Fehlt die Begründung, gibt das Modell statt einer starken Schwachstellenbehauptung ein einzelnes nächstes Ziel zur Überprüfung zurück. Dies ist ein Prompt-Level-Evidenzvertrag; der aktuelle Parser validiert die Vollständigkeit jeder Evidenz nicht automatisch. Da die Ingestion Urteile und nächste Ziele normalisiert, liegt die endgültige Evidenzvalidierung in der Verantwortung des Menschen.

F. Design-Abstammung

Der anfängliche Untersuchungsfluss geht auf die dateibasierte Analyse, die begrenzte Kontexterweiterung und die strukturierten Ergebnisse von Protect AIs vulnhuntr zurück [1]. Dieses Projekt überträgt diese Ideen nicht direkt auf die Analyse von Python-Anwendungen, sondern gestaltet sie neu rund um die userspace-erreichbare Kernel-Oberfläche, Kernel-Objekt-Lifetimes, Teardown-Pfade und syzbot-Überlappungen. Insbesondere die Trennung von Prioritätssignalen und Schwachstellenbeweis sowie die Prüfung der Erreichbarkeit vor der Bug-Klasse sind zentrale Designentscheidungen des Kernel-Harness.

III. Systemarchitektur

Abb. 1. Die External-Signal-Schicht wandelt vor der Modellinferenz berechnete Beobachtungen in gerankte Überprüfungseinheiten um. Sie verteilt Aufmerksamkeit, begründet aber keinen Schwachstellenbeweis.

TABELLE I — VERANTWORTLICHKEITEN DER HAUPTMODULE

IV. Methodik

A. Kandidatenfindung und Bewertung

Der Scanner durchläuft .c- und .h-Dateien unter den Include-Verzeichnissen des Profils. Die Prioritätspunktzahl einer Datei f setzt sich konzeptionell wie folgt zusammen:

Diese Punktzahl ist kein Wahrscheinlichkeits- oder Exploitability-Maß. Jeder Eintrag liefert nur eine relative Reihenfolge, welche Dateien das Modell zuerst prüfen soll. Die aktuelle Implementierung summiert alle Line-Level-Treffer und begrenzt nur die im Prompt angezeigten Top-Signale. Die Neuberechnung desselben Ergebnisses setzt denselben Quellbaum, dasselbe Profil und denselben gecachten syzbot-JSON voraus. Das syzbot-Gewicht wird nachträglich auf Dateien angewendet, die zuerst durch Pfad- und Zeilenheuristiken zu Kandidaten wurden; syzbot-Treffer allein erzeugen keine neuen Kandidatendateien.

Die wichtigsten statischen Signale sind:

• ioctl, Compat-Handler, Dateioperations-Hooks
• copy_from_user, copy_to_user, __user
• kmalloc, kzalloc, kvmalloc, Cache-Allokation und Free-Pfade
• Refcount-, Atomic- und kref-Operationen
• Größen-/Längenberechnungen und memcpy-Familien
• Lock-, RCU- und asynchrone Lifetime-Muster
• BPF-, skb-, XDP- und Netlink-Grenzen
• Capability- und Namespace-Checks

B. Profilgesteuerter Umfang

Die eingebauten Profile sind default, net, fs, io_uring, bpf und drivers. Profile definieren Include-Pfade, Muster, Gewichte und die Anzahl der pro Datei zu erhaltenden Signale. Statt einer einzigen Scoring-Richtlinie für den gesamten Kernel spiegeln sie die Angriffsfläche und Lifetime-Eigenschaften der jeweiligen Subsysteme wider.

C. Crash-Intelligence

syzbot-fetch extrahiert Titel, Subsystem, Bug-Typ und Datei:Zeilen-Informationen aus den öffentlichen syzbot-Bug-Seiten des syzkaller-Projekts [2] und speichert sie in einem JSON-Cache. Exakte Dateiüberlappung ist ein starkes External Signal, Subsystemüberlappung ein schwaches. Da das Live-Dashboard variieren kann, ist die Reproduktionseinheit das zum Abrufzeitpunkt gespeicherte JSON. Crash-Informationen sind nur ein Ausgangspunkt für Variantenjagd und werden nicht als Beweis für neue Schwachstellen behandelt.

D. Sitzungs- und Überprüfungsvertrag

scan erzeugt ein geranktes Kandidatenmanifest und ein Top-Prompt-Bündel. Jeder Prompt enthält Zielpfad, Score-Begründung, Zeilensignale, syzbot-Kontext und das Audit-Verfahren.

Modellantworten werden in eines der folgenden Urteile normalisiert:

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

Die Antwort enthält ein einziges Single best next target und eine kurze Zusammenfassung. Alte Antworten ohne ausstehendes Ziel werden nicht mit neuen Zielen verknüpft, sondern separat archiviert.

V. Implementierung und Verwendung

A. Anforderungen

• Python 3.11 oder höher
• Codex CLI [3] und Authentifizierung bei Verwendung des Autopiloten
• Netzwerkverbindung für den Abruf des entfernten syzbot-Dashboards

B. Installation

Die eingebauten Profil-JSONs sind im Wheel enthalten. Externe JSON-Regeln können mit --config /path/to/profile.json übergeben werden.

C. Minimaler Workflow

--limit ist die Anzahl der im Manifest zu behaltenden Kandidaten, --top die Anzahl der anfänglich vorab erstellten Prompt-Bündel. Bündel für spätere Ränge können bei Bedarf ebenfalls erstellt werden.

D. Zeitbudgetierter Autopilot

Die Standard-Sandbox ist read-only. --sandbox workspace-write sollte nur angegeben werden, wenn Dateiänderungen während der Analyse unbedingt erforderlich sind.

E. Optionaler syzbot-Feed

F. Sitzungsartefakte

VI. Betriebsergebnis und Verifikation

Diese Version blieb kein Konzeptnachweis, sondern wurde in einer realen Linux-Kernel-Schwachstellenuntersuchung eingesetzt.

TABELLE II — VERÖFFENTLICHTES SCHWACHSTELLENERGEBNIS

Die Verifikation ist kein Benchmark für Erkennungsgenauigkeit, sondern konzentriert sich auf Implementierungsregressionen und Bereitstellbarkeit.

TABELLE III — UMFANG DER TECHNISCHEN VERIFIKATION

GitHub Actions führt Unit-Regressionstests aus, installiert dann das Wheel in einer neuen Umgebung und führt einen Smoke-Test des default-Profil-Scans durch. Das obige öffentliche Beispiel ist ein operatives Ergebnis aus realer Untersuchung, aber kein Benchmark für Precision, Recall oder CVE-Entdeckungsrate, gemessen an einem repräsentativen Linux-Tree-Korpus.

VII. Sicherheitshinweise

• Es wird empfohlen, die Standard-read-only-Sandbox beizubehalten.
• --dangerously-bypass-approvals-and-sandbox nicht ohne externe Sandbox verwenden.
• Auch nicht vertrauenswürdige Quellkommentare und Bezeichner können Modelleingaben sein; Prompt-Injection muss berücksichtigt werden.
• Vom Modell erzeugte Findings müssen vor Veröffentlichung oder Meldung von Menschen auf Erreichbarkeit und Auswirkung revalidiert werden.
• syzbot-Crashes und hohe heuristische Punktzahlen dürfen nicht als Schwachstellenbeweis angeführt werden.

VIII. Einschränkungen und Gültigkeitsbedrohungen

1. Lexikalische Analyse. Es wird kein echter C-AST, Call-Graph oder interprozeduraler Datenfluss erstellt.
2. Score-Verzerrung. 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 der öffentlichen HTML-Struktur betroffen.
5. Modellabhängigkeit. Die Ergebnisqualität hängt vom verwendeten Modell, der Prompt-Interpretation und dem Repository-Kontext ab.
6. Evaluationsumfang. Die aktuellen Tests validieren Software-Regressionen. Das veröffentlichte CVE-Beispiel ist ein reales Nutzungsergebnis, ersetzt aber keine statistische Bewertung der Sicherheitserkennungsleistung.

IX. Retrospektive

Von der in der Git-Historie dokumentierten ersten Version an war das Ziel weniger „das LLM Schwachstellen selbst finden zu lassen“ als vielmehr „zu kontrollieren, welcher Code zuerst geprüft und welche Evidenz verlangt wird“. Die v1-unterstützte Untersuchung, die CVE-2026-31720 fand, lieferte ein Beispiel dafür, dass enge Untersuchungseinheiten und ein Evidenzvertrag in der realen Forschung anwendbar sind. v2 erweitert diesen Workflow zu einem Provenance-bewussten Triage, der Repository-Zustand und bekannte Referenzen gemeinsam bewahrt. Würde ich es heute neu implementieren, hätte Folgendes Priorität:

1. tree-sitter- oder Clang-basierter Symbol-/Call-Graph,
2. Score-Normalisierung unter Berücksichtigung von Dateigröße und wiederholten Treffern,
3. Entfernung von CLI-/Autopilot-Redundanz durch Trennung der review- und runner-Ebenen,
4. versionierte Manifeste und atomare Zustandsschreibvorgänge,
5. JSON-Schema-basierte Modellantworten und strukturierte Evidenz,
6. automatische Verknüpfung von syzbot-Crashes, Fix-Commits und nahen Varianten.

Dennoch bleibt das zentrale Prinzip, das ich beibehalten möchte, External Signal. Dem LLM nicht die gesamte Codebasis vage durchsuchen lassen, sondern durch Signale außerhalb des Modells eingegrenzte Untersuchungseinheiten iterativ mit Fokus auf Erreichbarkeit und Invarianten bearbeiten.

X. Fazit

Kernel Codex Harness ersetzt nicht die Erkennung von Linux-Kernel-Schwachstellen. Stattdessen wandelt es External Signal in erklärbare Rankings um und beschränkt die LLM-Prüfung auf kurze, zustandsbehaftete Untersuchungsprozesse. Diese Struktur wurde in einer realen Untersuchung zur Entdeckung von CVE-2026-31720 verwendet. Das Kernresultat des Projekts liegt nicht in der Behauptung eines neuen Analysealgorithmus, sondern darin, LLM-Sicherheitsprüfung als External-Signal-Aufmerksamkeitsallokation, Evidenzvertrag und reproduzierbare Orchestrierung zu definieren und in einem realen Forschungs-Workflow anzuwenden.

Anhang A. Repository-Struktur

Detaillierte Betriebsabläufe finden Sie in docs/.

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.