Index Terms— Linux kernel, vulnerability research, external signal, LLM orchestration, heuristic prioritization, syzbot, program analysis, Codex.

I. Introduction

La revisión de seguridad del kernel de Linux tiene dos tipos de problemas de escala. Primero, todo el árbol fuente es demasiado grande para manejarlo en un solo contexto de LLM. Segundo, señales como copy_from_user, allocators, refcount y locks son comunes, pero por sí solas no implican una vulnerabilidad. El analista primero debe decidir “dónde mirar” y luego probar por separado la reachability desde userspace y las transiciones de estado concretas.

La filosofía central de este proyecto es External Signal.

No dejamos que el LLM decida por sí mismo dónde mirar. Las señales reproducibles fuera de la inferencia del modelo asignan la atención, pero las conclusiones sobre vulnerabilidades se determinan únicamente con evidencia de reachability e invariantes.

Por lo tanto, el harness no hace que el modelo explore vagamente todo el kernel. Prioriza archivos, presenta una sola rama de investigación a la vez y exige primero estructura de evidencia en lugar de conclusiones.

II. External Signal and Design Principles

A. External Signal Before Model Inference

External Signal no es un juicio generado por el LLM, sino una observación determinada antes de la ejecución del modelo y recalculable a partir del mismo árbol fuente, perfil y JSON de syzbot almacenado. Los pesos de ruta, los hits de expresiones regulares y el solapamiento cacheado con syzbot entran en esta categoría. Esta señal se usa solo para clasificar candidatos y para el contexto del prompt; no se promueve a veredicto ni a prueba.

En este documento, External Signal se refiere a toda la filosofía del proyecto. El modelo de datos ExternalSignal en el código representa actualmente solo las señales derivadas de syzbot, por lo que el alcance de ambos términos es diferente.

B. Prioritization Is Not Proof

Los hits de expresiones regulares, las rutas de alto riesgo y el solapamiento con syzbot son señales para el orden de investigación. Una puntuación alta no constituye un hallazgo de seguridad si la ruta de llamada real, los privilegios, la configuración del kernel, el namespace o la disponibilidad del dispositivo no permiten el acceso del atacante.

C. Reachability Before Bug Class

La auditoría primero verifica los límites que se originan en userspace, como syscall, ioctl, netlink, procfs, filesystems, BPF y hooks de drivers. Solo después evalúa clases de bugs como UAF, OOB, refcount, race, info leak y comprobaciones de capabilities.

D. One Investigation Branch at a Time

Una unidad de investigación se limita, por defecto, a un archivo y sus callers, teardown y rutas de free cercanos. Los follow-ups manuales recomendados por el modelo se permiten como máximo dos veces. Esta limitación no busca reducir la capacidad de exploración, sino mantener las conclusiones dentro de un alcance verificable.

E. Evidence Over Confidence

El prompt exige que un hallazgo fuerte explique al menos los siguientes elementos:

1. entrypoint alcanzable por el atacante,
2. campo controlado por el atacante o transición de lifetime,
3. invariante de objeto·longitud·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.

Si la evidencia es insuficiente, el modelo devuelve un único objetivo para verificar a continuación en lugar de afirmar con fuerza una vulnerabilidad. Este es un contrato de evidencia a nivel de prompt; el parser actual no verifica automáticamente la completitud de cada evidencia. La ingesta normaliza el veredicto y el siguiente objetivo, por lo que la verificación final de la evidencia es responsabilidad humana.

F. Design Lineage

El flujo de investigación inicial partió de las ideas de análisis por archivo, expansión limitada de contexto y resultados estructurados utilizadas por vulnhuntr de Protect AI [1]. En este proyecto no se aplicó tal cual al análisis de aplicaciones Python, sino que se rediseñó en torno a la superficie del kernel alcanzable desde userspace, el lifetime de objetos del kernel, las rutas de teardown y el solapamiento con syzbot. En particular, separar las señales de priorización de la prueba de vulnerabilidad y verificar la reachability antes que la clase de bug es la decisión de diseño central del harness para kernel.

III. System Architecture

Fig. 1. La capa de External Signal convierte observaciones calculadas antes de la inferencia del modelo en unidades de revisión clasificadas. Asigna atención, pero no establece prueba de vulnerabilidad.

TABLA I — RESPONSABILIDADES DE LOS MÓDULOS PRINCIPALES

IV. Methodology

A. Candidate Discovery and Scoring

El escáner recorre los archivos .c y .h bajo el directorio include del perfil. La puntuación de prioridad del archivo f se compone conceptualmente de la siguiente manera:

Esta puntuación no es una medida de probabilidad ni de explotabilidad. Cada término solo proporciona un orden relativo para que el modelo decida qué archivo revisar primero. La implementación actual suma todas las coincidencias a nivel de línea y limita las señales principales que se muestran en el prompt. El recálculo del mismo resultado presupone el mismo árbol fuente, perfil y JSON de syzbot cacheado. El peso de syzbot se aplica a posteriori a los archivos que ya fueron candidatos mediante las heurísticas de ruta·línea; un hit de syzbot por sí solo no genera nuevos archivos candidatos.

Las principales señales estáticas son:

• ioctl, handlers compat, hooks de file operation
• copy_from_user, copy_to_user, __user
• kmalloc, kzalloc, kvmalloc, asignación de caché y rutas de free
• operaciones de refcount, atomic, kref
• cálculos de tamaño·longitud y familias de memcpy
• patrones de lock, RCU y lifetime asíncrono
• límites de BPF, skb, XDP y netlink
• comprobaciones de capabilities y namespace

B. Profile-Driven Scope

Los perfiles integrados son default, net, fs, io_uring, bpf y drivers. El perfil define rutas include, patrones, pesos y la cantidad de señales a conservar por archivo. En lugar de aplicar una única política de puntuación a todo el kernel, se reflejan la superficie de ataque y las características de lifetime de cada subsistema.

C. Crash Intelligence

syzbot-fetch extrae de las páginas públicas de bugs de syzbot del proyecto syzkaller [2] el título, subsistema, tipo de bug e información de file:line, y lo guarda en una caché JSON. El solapamiento exacto de archivos es una External Signal fuerte; el solapamiento de subsistema es una External Signal débil. Como el dashboard en vivo puede cambiar, la unidad de reproducción es el JSON guardado en el momento de la descarga. La información de crashes es solo un punto de partida para la búsqueda de variantes, no se trata como prueba de una nueva vulnerabilidad.

D. Session and Review Contract

scan genera un manifest de candidatos clasificados y un bundle de prompts principales. Cada prompt incluye la ruta objetivo, la razón de la puntuación, las señales de línea, el contexto de syzbot y el procedimiento de auditoría.

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 respuesta incluye un único Single best next target y un resumen breve. Las respuestas antiguas sin objetivo pendiente se archivan por separado y no se conectan a nuevos objetivos.

V. Implementation and Usage

A. Requirements

• Python 3.11 o superior
• Codex CLI [3] y autenticación si se usa autopilot
• Conexión de red para la recolección remota del dashboard de syzbot

B. Installation

Los JSON de perfiles integrados se incluyen en el wheel. Las reglas JSON externas se pueden pasar con --config /path/to/profile.json.

C. Minimal Workflow

--limit es la cantidad de candidatos que se mantienen en el manifest; --top es la cantidad de bundles de prompt que se generan por adelantado. Los bundles de rangos posteriores también se pueden generar bajo demanda.

D. Time-Budgeted Autopilot

El sandbox por defecto es read-only. Solo se debe especificar --sandbox workspace-write si la modificación de archivos es estrictamente necesaria durante el análisis.

E. Optional syzbot Feed

F. Session Artifacts

VI. Operational Outcome and Verification

Esta versión no se quedó en una prueba de concepto; se usó en una investigación real de vulnerabilidades del kernel de Linux.

TABLA II — RESULTADO DE VULNERABILIDAD DIVULGADA

La verificación no es un benchmark de precisión de detección, sino que se centra en la regresión de la implementación y su capacidad de despliegue.

TABLA III — ALCANCE DE VERIFICACIÓN DE INGENIERÍA

GitHub Actions ejecuta las regresiones unitarias, luego instala el wheel en un entorno nuevo y hace un smoke-test del escaneo con el perfil default. El caso público anterior es un resultado operativo obtenido en una investigación real, pero no es un benchmark de precisión, recall ni tasa de descubrimiento de CVEs medido sobre un corpus representativo de árboles de Linux.

VII. Safety Considerations

• Se recomienda mantener el sandbox read-only por defecto.
• En entornos sin sandbox externo, no se debe usar --dangerously-bypass-approvals-and-sandbox.
• Los comentarios e identificadores de fuentes no confiables también pueden ser entrada del modelo, por lo que se debe considerar la inyección de prompts.
• Los hallazgos generados por el modelo deben ser revalidados por humanos en cuanto a reachability e impacto antes de su divulgación o informe.
• No se deben citar crashes de syzbot ni puntuaciones heurísticas altas como prueba de vulnerabilidad.

VIII. Limitations and Threats to Validity

1. Análisis léxico. No se construye un AST real de C, grafo de llamadas ni flujo de datos interprocedural.
2. Sesgo de puntuación. Los comentarios, macros, tokens repetidos y archivos grandes pueden influir excesivamente en la puntuación.
3. Brecha de reachability. La configuración del kernel, privilegios, namespace y 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. Dependencia del modelo. La calidad de los resultados depende del modelo utilizado, la interpretación del prompt y el contexto del repositorio.
6. Alcance de la evaluación. Las pruebas actuales verifican regresiones 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. Retrospective

Desde la primera versión registrada en el historial de Git, el objetivo estuvo más cerca de “controlar qué código revisar primero y qué evidencia exigir” que de “hacer que el LLM encuentre vulnerabilidades por sí solo”. La investigación asistida por v1 que descubrió CVE-2026-31720 proporcionó un caso de aplicación real de la unidad de investigación reducida y el contrato de evidencia. v2 extendió este workflow hasta un triage consciente de procedencia que conserva el estado del repositorio junto con referencias conocidas. Si lo reimplementara hoy, priorizaría lo siguiente:

1. grafo de símbolos/llamadas basado en tree-sitter o Clang,
2. normalización de puntuación que considere el tamaño del archivo y los hits repetidos,
3. separación de las capas review y runner para eliminar la duplicación entre CLI y autopilot,
4. manifest versionado y escritura atómica de estado,
5. respuestas de modelo y evidencia estructurada basadas en JSON Schema,
6. conexión automática de crashes de syzbot, commits de fix y variantes cercanas.

Aun así, el principio central que quiero conservar es External Signal. No dejar que el LLM explore vagamente toda la base de código; repetir unidades de investigación reducidas por señales externas al modelo, centradas en reachability e invariantes.

X. Conclusion

Kernel Codex Harness no reemplaza la detección de vulnerabilidades del kernel de Linux. En cambio, convierte External Signal en una clasificación explicable y limita la revisión del LLM a un proceso de investigación corto y con estado. Esta estructura se usó en una investigación real para descubrir CVE-2026-31720. El resultado central del proyecto no es afirmar un nuevo algoritmo de análisis, sino definir la revisión de seguridad con LLM como un problema de asignación de atención por señal externa, contrato de evidencia y orquestación reproducible, y aplicarlo a un workflow de investigación real.

Appendix A. Repository Layout

Los procedimientos operativos detallados están disponibles en docs/.

References

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

License

Licenciado bajo la Apache License 2.0.