foxirain/linux-kernel-codex-harnessHerramienta de investigación de vulnerabilidades del kernel de Linux basada en evidencia, utilizada en la investigación de CVE-2026-31720
Herramienta de investigación · Importación original: 3 de abril de 2026 · Revisión de documentación: 11 de julio de 2026
Filosofía central — Señal externa
Deja que las observaciones reproducibles fuera de la inferencia del modelo guíen la atención; nunca confundas prioridad con prueba.
Estado del proyecto. Este repositorio es una versión inicial de un harness de investigación asistido por LLM que construí y usé para la investigación real de vulnerabilidades del kernel de Linux. Esta versión se utilizó para descubrir la vulnerabilidad publicada como CVE-2026-31720. El harness prioriza los objetivos de investigación, pero no prueba vulnerabilidades automáticamente ni garantiza la seguridad del kernel; la validación final y la divulgación las realiza un humano.
Abstract— Explorar una base de código tan grande como el kernel de Linux directamente con un LLM dispersa rápidamente el contexto y confunde fácilmente la existencia de APIs peligrosas con la explotabilidad real. Kernel Codex Harness define este problema no como detección automática de vulnerabilidades, sino como priorización de investigación y orquestación basada en estado. Este proyecto denomina External Signal al principio de controlar la atención del modelo mediante observaciones reproducibles calculadas fuera de la inferencia del LLM. Combina rutas del kernel, límites de userspace, señales estáticas relacionadas con lifetime·usercopy·refcount·size e inteligencia opcional de crashes de syzbot para clasificar archivos candidatos y convertir cada candidato en un paquete de prompts reducido. La revisión manual y el autopilot basado en presupuesto de tiempo utilizan el mismo contrato de respuesta y estado de sesión. Este harness se usó en una investigación real del kernel de Linux para descubrir un stack out-of-bounds write en la ruta de audio del gadget USB; ese defecto se publicó como CVE-2026-31720. Esta implementación no es un analizador estático de precisión, sino un workflow de investigación que limita el alcance del LLM mediante heurísticas explicables; todos los hallazgos requieren revalidación humana de reachability, invariantes rotas e impacto concreto.
Index Terms— Linux kernel, vulnerability research, external signal, LLM orchestration, heuristic prioritization, syzbot, program analysis, Codex.
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.
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.
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.
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.
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.
El prompt exige que un hallazgo fuerte explique al menos los siguientes elementos:
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.
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.
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
