foxirain/linux-kernel-codex-harness-v2Herramienta de investigación de vulnerabilidades del kernel de Linux consciente de la procedencia, utilizada en la investigación de CVE-2026-53075
Herramienta de Investigación · Importación Original: 3 de abril de 2026 · Revisión de Documentación v2: 11 de julio de 2026
Señal Externa: De la Asignación de Atención al Triage Consciente de Procedencia
Usa observaciones reproducibles para guiar la atención del modelo, luego usa la procedencia del repositorio para organizar las colas de revisión—nunca para reclamar prueba.
Linaje del Proyecto— Kernel Codex Harness v1 · Asignación de Atención → Kernel Codex Harness v2 · Triage Consciente de Procedencia
Estado del proyecto. Este repositorio es un harness de investigación asistido por LLM que evoluciona el workflow de asignación de atención de v1 hasta el triage consciente de procedencia para la investigación real de vulnerabilidades del kernel de Linux. Esta versión se usó para descubrir la vulnerabilidad publicada como CVE-2026-53075. No es un detector automático de vulnerabilidades, un juez de novedad, un validador de exploits ni una herramienta de garantía de seguridad del kernel; la validación final y la divulgación las realiza un humano.
Abstract— Hacer que un LLM explore directamente una base de código tan grande como el kernel de Linux dispersa el contexto y confunde fácilmente la existencia de APIs peligrosas con la explotabilidad real. Kernel Codex Harness v2 define este problema como un procesamiento de Señal Externa en dos etapas. Antes de la llamada al modelo, los pesos de ruta, los aciertos léxicos y la superposición con syzbot en caché clasifican los archivos candidatos para asignar la atención. Después de la respuesta del modelo, se combinan la rama Git, el HEAD, el estado sucio y los marcadores CVE, commit y conocidos extraídos de la respuesta para clasificar los hallazgos fuertes en buckets de revisión conscientes de procedencia. Este harness se usó en una investigación real del kernel de Linux para descubrir una falla en la verificación de permisos del namespace de red objetivo de PPP, publicada como CVE-2026-53075. El triage es una heurística para organizar la cola de investigación; en particular, new_candidate solo significa que no se encontraron pistas conocidas ni problemas de procedencia, no es una prueba de novedad. Todos los hallazgos requieren revalidación humana de alcanzabilidad desde userspace, ruptura de invariantes e impacto concreto.
Términos de índice— kernel de Linux, investigación de vulnerabilidades, señal externa, procedencia, triage heurístico, orquestación de LLM, syzbot, Codex.
La revisión de seguridad del kernel tiene dos tipos diferentes de incertidumbre.
El problema central de v1 era el primero, la asignación de atención. v2 mantiene ese principio y extiende el segundo problema al triage consciente de procedencia. Ambas versiones se usaron en investigaciones reales: la investigación asistida por v1 condujo a CVE-2026-31720 y la asistida por v2 condujo a CVE-2026-53075.
Las observaciones fuera del modelo reducen el alcance de la investigación y, después de la respuesta del modelo, se adjunta procedencia verificable del repositorio. Ninguna señal en ninguna etapa prueba una vulnerabilidad o novedad.
La Señal Externa pre-inferencia no es un juicio del LLM, sino una observación calculada antes de la ejecución del modelo.
Con el mismo árbol fuente, perfil y JSON de syzbot en caché, el ranking de candidatos se puede recalcular. Esta puntuación no es probabilidad ni explotabilidad, sino un orden relativo para decidir dónde mirar primero.
La etapa post-inferencia combina un veredicto fuerte del modelo con la siguiente información.
En este documento, la Señal Externa post-inferencia se refiere únicamente a la procedencia recopilada independientemente del modelo, como el repositorio Git/estado, la rama, el HEAD, el estado sucio y la ascendencia de commits locales. Los marcadores CVE, commit y conocidos son referencias derivadas del modelo extraídas de la respuesta del modelo, no Señal Externa ni hechos autoritativos. El triage combina ambos tipos de entrada pero registra sus fuentes por separado.
Los hallazgos fuertes se organizan operativamente en uno de los siguientes buckets de revisión.
| Bucket | Significado |
|---|---|
new_candidate | Candidato con procedencia confirmada y sin señales de bloqueo por estado sucio o problemas conocidos |
known_issue | Candidato con referencia conocida no negada o un commit señalado por la respuesta como fix/relación upstream y confirmado como ancestro del HEAD actual |
dirty_tree_suspect | Candidato donde no se puede descartar la influencia de un repositorio sucio o un objetivo sucio |
provenance_unknown | Candidato donde no se pudo confirmar de forma fiable el repositorio Git, el estado o el HEAD |
El novelty_proven de todos los resultados de clasificación es false. new_candidate no significa "nueva vulnerabilidad", sino una cola prioritaria para que un humano continúe la investigación de novedad.
La auditoría verifica primero los límites que se inician desde userspace, como syscall, ioctl, netlink, procfs, filesystem, BPF y hooks de drivers. Solo después evalúa clases de bug como UAF, OOB, refcount, race, info leak y comprobaciones de capabilities.
Una unidad de investigación se limita a un archivo y sus rutas cercanas de caller, teardown y free. El seguimiento manual propuesto por el modelo se limita a un máximo de dos veces para mantener rutas cortas verificables en lugar de una exploración amplia.
Un hallazgo fuerte debe explicar como mínimo lo siguiente.
El parser normaliza el veredicto y el siguiente objetivo, pero no prueba automáticamente la completitud de esta evidencia.
