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.

I. Introducción

La revisión de seguridad del kernel tiene dos tipos diferentes de incertidumbre.

1. Dónde mirar primero. El árbol fuente completo es demasiado grande para manejarlo en un solo contexto de modelo.
2. Cómo tratar los hallazgos fuertes del modelo. Modificaciones locales, fixes existentes, CVEs conocidos o un estado incompleto del repositorio pueden contaminar las conclusiones.

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.

II. Señal Externa y Principios de Diseño

A. Etapa 1 — Asignación de Atención Antes de la Inferencia

La Señal Externa pre-inferencia no es un juicio del LLM, sino una observación calculada antes de la ejecución del modelo.

• Pesos de rutas y subsistemas del kernel
• Aciertos léxicos como usercopy, allocator, refcount, size, lock
• Superposición de archivos/subsistemas con el JSON de syzbot almacenado

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.

B. Etapa 2 — Triage Consciente de Procedencia Después de la Inferencia

La etapa post-inferencia combina un veredicto fuerte del modelo con la siguiente información.

• Si es un repositorio Git y si la recopilación de estado fue exitosa
• Rama y HEAD
• Estado sucio del repositorio y del archivo objetivo
• CVE, hash de commit y marcadores de problemas conocidos extraídos de la respuesta
• Expresiones de negación o referencias no relacionadas en la respuesta

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.

C. Buckets Heurísticos, No Prueba de Novedad

Los hallazgos fuertes se organizan operativamente en uno de los siguientes buckets de revisión.

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.

D. Alcanzabilidad Antes que Clase de Bug

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.

E. Una Rama de Investigación a la Vez

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.

F. Evidencia Sobre Confianza

Un hallazgo fuerte debe explicar como mínimo lo siguiente.

1. entrypoint alcanzable por el atacante,
2. campo controlado por el atacante o transición de lifetime,
3. invariante de objeto, longitud o estado que se rompe,
4. impacto concreto como corrupción, fuga o escalada de privilegios,
5. por qué las comprobaciones existentes no impiden el ataque.

El parser normaliza el veredicto y el siguiente objetivo, pero no prueba automáticamente la completitud de esta evidencia.

G. Linaje de Diseño

El flujo inicial se inspiró en las ideas de análisis por archivo, extensión limitada de contexto y resultados estructurados utilizadas por vulnhuntr de Protect AI [1]. En este proyecto se rediseñó para la superficie del kernel alcanzable desde userspace, el lifetime de objetos del kernel, las rutas de teardown y la superposición con syzbot. La contribución adicional de v2 es colocar una etapa de triage de hallazgos basada en la procedencia del repositorio después de la asignación de atención.

III. Arquitectura del Sistema

Fig. 1. La Señal Externa pre-inferencia clasifica unidades de revisión reproducibles. El triage post-inferencia combina la procedencia Git independiente del modelo con las referencias de respuesta derivadas del modelo, sin tratar estas últimas como Señal Externa ni hecho autoritativo. La validación humana permanece fuera de ambas etapas automatizadas.

TABLA I — RESPONSABILIDADES DE LOS MÓDULOS PRINCIPALES

IV. Metodología

A. Descubrimiento y Puntuación de Candidatos

El escáner recorre los archivos .c y .h bajo el directorio de includes del perfil.

La implementación actual suma las coincidencias a nivel de línea y solo limita el número de señales principales mostradas en el prompt. La puntuación ordena la secuencia de investigación del modelo, pero no es un valor estadístico calibrado de probabilidad de vulnerabilidad.

Las principales señales estáticas son las siguientes.

• ioctl, handlers compat, hooks de operaciones de archivo
• copy_from/to_user y __user
• kmalloc/kzalloc/kvmalloc, asignación de caché y rutas de free
• refcount, atomic, kref
• cálculos de size·length y familias de memcpy
• lock, RCU, lifetime asíncrono
• BPF, skb, XDP, netlink
• comprobaciones de capabilities y namespaces

B. Alcance Impulsado por Perfiles

C. Inteligencia de Crashes

syzbot-fetch extrae título, subsistema, tipo de bug y archivo:línea de las páginas públicas de bugs de syzbot y los guarda en JSON. La superposición exacta de archivos es una señal de ranking fuerte; la superposición de subsistemas es una señal débil. Como el dashboard en vivo puede cambiar, la unidad reproducible es el JSON almacenado en el momento de la descarga. La superposición de crashes es una pista para la caza de variantes, no evidencia de vulnerabilidad.

D. Contrato de Sesión y Revisión

scan genera el manifest completo de candidatos clasificados y el bundle de prompts principales. --limit es el número de candidatos que se mantienen en el manifest y --top es el número de bundles generados por adelantado. Los rankings posteriores también se pueden generar bajo demanda.

La respuesta del modelo se normaliza a uno de los siguientes veredictos.

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

La revisión manual y el autopilot usan el mismo review_state.json, la ruta de respuesta fija y el parser de veredictos.

E. Recopilación de Procedencia y Triage

doctor y el autopilot verifican si es un repositorio Git, si la recopilación de estado fue exitosa, la rama, el HEAD y las rutas sucias. Un estado donde no se puede confirmar la procedencia no se trata como limpio, sino que se conserva como provenance_unknown.

El triage de veredictos fuertes sigue aproximadamente esta prioridad.

1. Si la procedencia no es fiable, provenance_unknown,
2. Si el repositorio o el objetivo está sucio, dirty_tree_suspect,
3. Si hay un CVE relacionado o un marcador no negado, o si la respuesta señala un commit como fix/relación upstream que es ancestro del HEAD actual, known_issue,
4. De lo contrario, new_candidate.

Expresiones de negación o no relacionadas como "not a known issue" o "unrelated to CVE-…" no se usan como base de conocimiento. En el veredicto final se registran, junto con el veredicto original, la rama, el HEAD, el estado, el estado sucio, la referencia coincidente y el motivo.

Actualmente, la clasificación en buckets conscientes de procedencia y el escritor JSONL se aplican a la ruta de ingest del autopilot. El loop e ingest manuales usan el mismo estado de sesión base y el parser de veredictos, pero no generan artefactos de buckets.

V. Implementación y Uso

A. Requisitos

• Python 3.11 o superior
• Árbol fuente del kernel de Linux
• Git para usar provenance/doctor/autopilot
• CLI de Codex y autenticación para usar autopilot [3]
• Conexión de red para la recopilación remota de syzbot

Las dependencias de runtime de Python son solo la biblioteca estándar.

B. Instalación

Los perfiles JSON integrados se incluyen en la wheel. Se pueden pasar reglas adicionales con --config /path/to/profile.json.

C. Workflow Mínimo

La respuesta manual de Codex se guarda en codex_response.txt según lo especifica el runbook y luego se puede ingerir con el siguiente comando.

D. Autopilot con Presupuesto de Tiempo

El sandbox de Codex tiene como valor predeterminado read-only. --require-clean-tree solo permite la ejecución cuando se confirman el repositorio Git, el estado y el HEAD, y el árbol de trabajo está limpio. --stop-on-finding se detiene solo cuando el resultado del triage heurístico es new_candidate.

E. Feed Opcional de syzbot

F. Artefactos de Sesión

AUTOPILOT_FINDINGS.jsonl conserva el veredicto, el bucket, el motivo, la rama, el HEAD, el estado de procedencia, la referencia coincidente y las rutas de hallazgo/archivo en un formato procesable.

VI. Resultado Operativo y Verificación

v2 aplicó la estructura extendida a una investigación real de vulnerabilidades del kernel de Linux.

TABLA II — RESULTADO DE VULNERABILIDAD DIVULGADA

Las 16 pruebas de regresión no son un benchmark de precisión de detección de seguridad, sino que se centran en el contrato de software y la capacidad de distribución.

• Regresión de recursos de allocator y perfiles integrados
• Que los veredictos negativos y las expresiones CVE en prosa general no se inviertan en hallazgos fuertes
• Límite de seguimiento manual y orden de ranking
• Archivado de respuestas obsoletas sin objetivo pendiente
• Sandbox de solo lectura predeterminado y argumento CLI positivo
• Procedencia fail-closed para repositorio faltante/no-Git/fallo de estado
• Triage de objetivo sucio, referencia conocida, negación y CVE no relacionado
• Conservación del historial de sesión y JSONL de metadatos de clasificación
• Contrato de artefactos de errores de parseo y hallazgos
• Smoke test de escaneo de perfil desde la wheel instalada

GitHub Actions ejecuta las pruebas de regresión en Python 3.11 y 3.12, instala la wheel y hace smoke-test de los 6 perfiles empaquetados y del escaneo predeterminado. El caso público anterior es un resultado operativo obtenido en una investigación real, pero no es un benchmark de precisión, recall, explotabilidad o tasa de descubrimiento de CVEs medido sobre un corpus representativo de árboles de Linux.

VII. Consideraciones de Seguridad

• El sandbox de Codex tiene como valor predeterminado read-only y se recomienda mantenerlo.
• Si la procedencia limpia es importante, usa --require-clean-tree después de doctor.
• No interpretes un repositorio no-Git o un fallo de confirmación de estado/HEAD como limpio.
• --dangerously-bypass-approvals-and-sandbox no debe usarse fuera de un entorno experimental aislado.
• Los comentarios e identificadores del código fuente también son entradas del modelo, por lo que se debe considerar la posibilidad de prompt injection.
• Las cadenas CVE y commit son solo referencias de respuesta, no confirmaciones autoritativas.
• Antes de divulgar o informar un hallazgo, un humano debe revalidar la alcanzabilidad, los invariantes, el impacto y la versión afectada.

VIII. Limitaciones y Amenazas a la Validez

1. Análisis léxico. No se construye un AST C real, grafo de llamadas ni flujo de datos interprocedimental.
2. Sesgo de puntuación. Los comentarios, macros, tokens repetidos y archivos grandes pueden influir excesivamente en la puntuación.
3. Brecha de alcanzabilidad. La configuración del kernel, los privilegios, los namespaces y la disponibilidad de dispositivos no se modelan automáticamente.
4. Fragilidad de datos externos. La integración con syzbot se ve afectada por cambios en la estructura del HTML público.
5. Solo procedencia local. La ascendencia Git se basa en el HEAD del checkout actual y no representa todo el historial upstream o de vendors.
6. Referencias derivadas de la respuesta. Los CVE y marcadores conocidos se extraen de la respuesta del modelo, por lo que existe la posibilidad de omisión, alucinación o malentendido del contexto.
7. Triage heurístico. Tanto new_candidate como known_issue no son un veredicto final de novedad.
8. Dependencia del modelo. La calidad de los resultados depende del modelo, la interpretación del prompt y el contexto disponible del repositorio.
9. Alcance de la evaluación. Las pruebas actuales verifican la regresión de software. El caso CVE público es un resultado de uso real, pero no reemplaza una evaluación estadística del rendimiento de detección de seguridad.

IX. Evolución y Retrospectiva

v1 (repositorio) se centró en el problema de asignar la atención del LLM mediante Señal Externa y se usó en una investigación real asistida por v1 que descubrió CVE-2026-31720. v2 continúa la misma filosofía de investigación y la extiende para registrar el estado del repositorio y las referencias derivadas de la respuesta incluso después de que el modelo emite un hallazgo fuerte. En una investigación posterior que usó esta estructura se descubrió CVE-2026-53075.

Hay dos principios que deben mantenerse en esta evolución.

1. No malinterpretar la puntuación pre-inferencia como prueba de vulnerabilidad.
2. No malinterpretar el bucket post-inferencia como prueba de novedad.

Si se extendiera de nuevo, se priorizarían el grafo de llamadas de Clang/tree-sitter, la normalización de puntuaciones, el manifest versionado con bloqueo de estado entre procesos, un adaptador de base de datos autoritativa de CVE/fixes y la separación de runner, triage y escritor de artefactos. La escritura de estado actual usa archivos temporales y reemplazo atómico.

X. Conclusión

Kernel Codex Harness v2 no reemplaza la detección de vulnerabilidades. Antes de la llamada al modelo, la Señal Externa distribuye el presupuesto de investigación entre candidatos explicables; después de la llamada al modelo, la señal de procedencia organiza los hallazgos fuertes en colas revisables. Esta estructura se usó en una investigación real para descubrir CVE-2026-53075, y el resultado central del proyecto no es un algoritmo que determine automáticamente la novedad, sino un workflow práctico de revisión de seguridad con LLM que separa explícitamente la asignación de atención y el triage consciente de procedencia.

Apéndice A. Estructura del Repositorio

La operación manual detallada se puede consultar en la guía de Codex CLI, la ejecución automática y el triage en la guía de Autopilot y la inteligencia de crashes en la guía de syzbot.

Referencias

[1] Protect AI, "vulnhuntr," repositorio de GitHub. https://github.com/protectai/vulnhuntr

[2] Google, "syzkaller and syzbot," repositorio de GitHub. https://github.com/google/syzkaller

[3] OpenAI, "Codex CLI." https://developers.openai.com/codex/cli/

Licencia

Licenciado bajo la Apache License 2.0.