A finales de septiembre de 2026, dos historias contaron ese papel desde ángulos opuestos, según la investigación de XBOW del 28 de septiembre y el debate sobre revisión automática en la lista del kernel. Por un lado, un sistema autónomo encontró y explotó un fallo que revisores humanos habían pasado por alto. Por otro, la comunidad discutía Sashiko, una propuesta para revisar cambios del kernel con ayuda de agentes.
El fallo, registrado como CVE-2026-72018, permitía a un usuario local con capacidades de red escalar a root con una escritura de apenas 16 bytes a cero en el lugar exacto. Parece poca cosa, como forzar una cerradura con un clip, pero colocada en el lugar exacto abre la puerta principal. XBOW demostró el camino completo hasta una shell con uid cero, sin fugas de memoria adicionales ni cadenas complejas.
Una semana después, con el parche ya aprobado en julio y el CVE publicado en agosto, la pregunta interesante no es si actualizar, que también, sino qué enseña este caso sobre revisar código con IA y dónde sigue haciendo falta criterio humano experto.
Sashiko el rastreador de bugs del kernel Linux
Sashiko es una propuesta para revisar cambios del kernel con agentes que leen parches, buscan patrones peligrosos y piden contexto cuando algo no cuadra. La idea se discutió en la lista de correo del kernel como respuesta a un problema de escala, porque cada versión trae miles de cambios y los revisores humanos no dan abasto. No sustituye la firma de un mantenedor, pero puede ordenar la cola por riesgo.
El momento no es casual. El 1 de octubre, el mantenedor Greg Kroah-Hartman describió una avalancha de reportes ayudados por modelos, con muchas falsas alarmas entre avisos válidos. En ese entorno, una herramienta que revise con criterio y explique sus hallazgos vale más que otra que genere candidatos en masa. Sashiko apunta a lo primero, con trazabilidad de por qué marca cada parche.
Un vistazo a la plataforma Sashiko y los bugs que están bajo revisión ahora en el kernel Linux
Para un lector no técnico, imagina un corrector que no solo subraya faltas, sino que pregunta al autor por qué cambió una frase delicada. Esa conversación deja rastro y ayuda al editor final a decidir. En el kernel, el editor final siempre es humano, y el agente es un ayudante incansable que no se duerme en la página mil.
¿Qué fallo encontró XBOW en el kernel?
El fallo vive en la pila SMC-D, un protocolo de IBM para comunicar máquinas virtuales por memoria compartida que evita copiar datos como hace TCP. Durante años exigió hardware específico de mainframe, así que casi nadie lo auditaba en portátiles normales. Con la abstracción DIBS y el controlador dibs_loopback, ese código empezó a correr en cualquier x86 por loopback, sin hardware especial.
El problema es conceptual y fácil de contar. Al establecer la conexión, el interlocutor envía campos como token, índice y tamaño que el receptor debe validar antes de calcular desplazamientos. El kernel multiplicaba tamaño por índice para obtener el desplazamiento de escritura sin comprobar rangos, así que un índice grande empujaba la copia más allá del búfer. La copia final hacía memcpy sobre la dirección base más ese desplazamiento sin preguntas.
El búfer legítimo mide 16384 bytes en una sola página de memoria, y lo que se escribe fuera de él es una cabecera de 32 bytes donde 16 son ceros predecibles. Dicho de forma doméstica, el programa escribía la carta en el sobre del vecino por fiarse del número de portal que le dictaron. Esa confianza sin verificación es el corazón de la CVE-2026-72018.
Explotar el fallo exigía primero hacerlo alcanzable en local. El camino normal fijaba el índice a cero, así que parecía sin salida para un atacante sin hardware. XBOW interceptó el tráfico loopback con NFQUEUE, falsificó los mensajes de handshake, recalculó sumas de comprobación y reinyectó los paquetes. Todo ello requiere CAP_NET_ADMIN, un permiso que tienen contenedores y demonios de red, por lo que el modelo de amenaza resulta realista.
Después tocaba convertir una escritura débil en escalada completa. El equipo reformuló la pregunta, en lugar de qué escribir dónde, se preguntó dónde duelen más los ceros. La respuesta fue la estructura cred, que guarda los identificadores de usuario y que el kernel consulta en cada control de permisos. Si el campo euid queda a cero, el proceso pasa por root.
La técnica de colocación es paciente y ruidosa a la vez. Primero se fija el búfer objetivo con el token de una conexión de calentamiento, después se lanzan muchos procesos hijo que fuerzan credenciales frescas para apilarlas tras el búfer. Cada hijo vigila su propio euid y avisa al padre al leer cero, que detiene el barrido antes de romper estructuras vecinas. En Ubuntu 24.04 con mitigaciones desactivadas, el prototipo logró root en 22 de 100 arranques.
Fase del exploit
Qué hace el atacante
Qué necesita
Interceptación
Falsifica índice y tamaño en loopback
CAP_NET_ADMIN y NFQUEUE
Escritura
Desplaza 16 ceros tras el búfer
Conexión SMC-D válida
Colocación
Apila cred detrás del búfer
Muchos procesos hijo
Escalada
Detecta euid cero y abre shell
setresuid a cero
El criterio humano siempre tendrá lugar
XBOW cuenta con honestidad los tres momentos donde una persona recondujo la investigación. Primero, cuando el índice a cero parecía un callejón sin salida, un investigador sugirió interceptar paquetes en tránsito. Segundo, cuando el agente confundía el modelo antiguo con escritura libre y el nuevo limitado a ceros, hubo que obligarlo a medir la primitiva experimentalmente. Tercero, cuando se empeñaba en convertir los ceros en algo más potente, hubo que pedirle que explotara lo que ya tenía.
Esas intervenciones dibujan bien la frontera actual. Los modelos leen código sin cansarse, prueban hipótesis tediosas y no abandonan por aburrimiento, pero desarrollan sesgos muy humanos cuando el contexto crece. Prefieren lo barato a lo costoso, entierran ideas que descartaron con una frase y se aferran a suposiciones como si fueran creencias. Alguien con experiencia en Linux sabe que escribir ceros donde toca puede bastar, y esa intuición orientó el final.
La respuesta arquitectónica que propone XBOW es repartir el trabajo entre varios agentes con contextos acotados, en lugar de cargar una campaña larga sobre uno solo. Cada agente conserva lo que necesita y olvida el resto, así las decisiones no se diluyen entre miles de líneas de historial. Es una lección organizativa además de técnica, porque la memoria también se gestiona.
El calendario ayuda a calibrar la urgencia sin alarmismo. El fallo se reportó el 19 de junio de 2026, el parche se aprobó el 7 de julio y el CVE se publicó el 17 de agosto, según la cronología de XBOW con referencia al anuncio en lore.kernel.org. A 9 de octubre, cuando escribimos, las distribuciones incluyen la corrección desde hace semanas. Si actualizaste el kernel después del verano, ya estás protegido.
Para flotas, la rutina es la conocida. Inventaría versiones, prioriza anfitriones con SMC cargado o con contenedores que otorguen CAP_NET_ADMIN, programa reinicios y verifica con uname menos r. En nubes públicas, las imágenes recientes ya llevan el parche, así que las máquinas nuevas arrancan cubiertas. No hay indicios de explotación masiva en este caso concreto, pero la ventana entre junio y agosto existió.
Un apunte para curiosos prudentes. Reproducir el exploit exige montar NFQUEUE y falsificar handshakes en tu propia máquina de laboratorio, nunca en sistemas ajenos. El valor didáctico está en entender validaciones y desplazamientos, no en probarlo donde no debes. Si te interesa la técnica, lee el informe completo y practica con máquinas desechables.
Comprueba la versión del kernel en cada anfitrión y compara con el aviso de tu distribución
Busca módulos SMC cargados y valora descargarlos si ningún servicio los usa
Revisa qué contenedores reciben CAP_NET_ADMIN y recorta ese permiso donde sobre
Programa el reinicio pendiente, porque el parche en disco no protege hasta arrancar
Cuando la IA revisa y también ataca
Este octubre deja una simetría que conviene retener. La misma familia de técnicas que ayuda a revisar parches con Sashiko es la que encontró un fallo olvidado y lo convirtió en root con XBOW. No son dos historias separadas, son dos caras del mismo microscopio más potente mirando el mismo código. La diferencia entre defensa y ataque está en quién formula la pregunta y con qué permiso actúa.
El kernel saldrá ganando si las revisiones automáticas explican sus motivos, enlazan pruebas y aceptan un no por respuesta. Perderá si nos ahogamos en candidatos sin contexto mientras los fallos reales esperan turno. Entre esos extremos, casos como la CVE-2026-72018 recuerdan una verdad sencilla, porque un código olvidado que de pronto corre en todas partes merece una revisión fresca con mentalidad adversaria.
