foxirain/linux-kernel-codex-harness-v2Provenance-bewusster Linux-Kernel-Schwachstellenforschungs-Harness, der bei der Untersuchung von CVE-2026-53075 verwendet wird.
Forschungswerkzeug · Originalimport: 3. April 2026 · v2-Dokumentationsrevision: 11. Juli 2026
Externes Signal: Von der Aufmerksamkeitsverteilung zum Provenienz-bewussten Triage
Reproduzierbare Beobachtungen nutzen, um die Modellaufmerksamkeit zu lenken, und anschließend die Repository-Provenienz nutzen, um Review-Warteschlangen zu organisieren – niemals, um einen Beweis zu beanspruchen.
Projektlinie— Kernel Codex Harness v1 · Aufmerksamkeitsverteilung → Kernel Codex Harness v2 · Provenienz-bewusstes Triage
Projektstatus. Dieses Repository ist ein LLM-gestützter Forschungs-Harness, der den Attention-Allocation-Workflow von v1 für reale Linux-Kernel-Schwachstellenuntersuchungen zu einem Provenienz-bewussten Triage weiterentwickelt. Diese Version wurde verwendet, um die als CVE-2026-53075 veröffentlichte Schwachstelle zu finden. Es ist kein automatischer Schwachstellendetektor, kein Neuheitsbewerter, kein Exploit-Verifizierer und kein Kernel-Sicherheitsgarantie-Werkzeug; die endgültige Validierung und Berichterstattung erfolgt durch Menschen.
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.
Die Sicherheitsüberprüfung des Kernels umfasst zwei verschiedene Arten von Unsicherheit.
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.
Pre-Inferenz-Externe-Signale sind Beobachtungen, die vor der Modellausführung berechnet werden, nicht LLM-Urteile.
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.
Die Post-Inferenz-Phase kombiniert ein starkes Modellurteil mit den folgenden Informationen.
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.
Starke Befunde werden betrieblich in einen der folgenden Review-Buckets eingeordnet.
| Bucket | Bedeutung |
|---|---|
new_candidate | Kandidat, dessen Provenienz bestätigt wurde und bei dem keine Dirty-/bekannten Blockiersignale gefunden wurden |
known_issue | Kandidat mit nicht-negierter bekannter Referenz oder bestätigtem Commit, den die Antwort als Fix/Upstream-Beziehung identifiziert und der im aktuellen HEAD enthalten ist |
dirty_tree_suspect | Kandidat, bei dem der Einfluss eines Dirty-Repositorys oder Dirty-Ziels nicht ausgeschlossen werden kann |
provenance_unknown | Kandidat, dessen Git-Repository, Status oder HEAD nicht zuverlässig verifiziert werden konnte |
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.
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.
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.
Ein starker Befund muss mindestens Folgendes erklären.
Der Parser normalisiert nur Urteil und nächstes Ziel; er beweist nicht automatisch die Vollständigkeit dieser Beweise.
