La reutilización de destinos de salto convierte código JIT descartado en una vía para filtrar datos mediante Spectre

Un grupo de investigadores ha hecho pública la técnica Branch Target Reuse (BTR), una variante de Spectre v2 que aprovecha las predicciones de salto que persisten después de retirar de la memoria código compilado justo a tiempo (JIT).

El equipo de VUSec, de la Vrije Universiteit Amsterdam, y de la Scuola Superiore Sant’Anna demostró la técnica contra el kernel de Linux. Para ello, empleó programas cBPF clásicos sin privilegios y extrajo el hash de la contraseña de root de un proceso su en ejecución.

El ataque filtró ocho bytes por segundo. Según una investigación publicada el 29 de septiembre de 2026, la recuperación completa tardó, de media, tres minutos en Intel Raptor Cove y cinco minutos en Intel Lion Cove.

El comportamiento subyacente del procesador se confirmó en todas las CPU probadas de Intel, AMD y Arm. Sin embargo, la viabilidad práctica del ataque varía según el entorno de software, la generación del procesador y las mitigaciones activadas.

Las predicciones obsoletas sobreviven al reciclaje de memoria JIT

Los procesadores modernos predicen el destino de los saltos indirectos para seguir ejecutando instrucciones sin esperar a que se determine el destino correcto. Los ataques de la familia Spectre manipulan o aprovechan este comportamiento especulativo para acceder a información que la ejecución arquitectónica no debería exponer.

BTR se centra en lo que ocurre cuando se recicla memoria ejecutable JIT.

Un motor JIT puede compilar un programa, colocar su código máquina en una dirección concreta y, más adelante, liberar ese código. Después, esa misma memoria puede albergar otro programa. Aunque los bytes almacenados hayan cambiado, el procesador puede conservar información sobre los destinos de salto asociados al código anterior.

Como consecuencia, un salto indirecto puede ejecutar especulativamente el código que ocupa ahora esa memoria, pero usando un destino obsoleto. Ese destino puede apuntar a una posición no prevista o desalineada dentro de la nueva secuencia de instrucciones.

Al final, la ejecución arquitectónica descarta la ruta incorrecta. Antes de que eso ocurra, sin embargo, las instrucciones especulativas pueden acceder a datos sensibles y modificar la caché. Un atacante puede medir esos efectos y deducir la información byte a byte.

Los investigadores describen este comportamiento como una primitiva especulativa de uso después de liberar: el procesador actúa como si una antigua relación de control de flujo siguiera siendo válida, aunque el código correspondiente ya no exista.

El ataque contra Linux recupera un hash de la contraseña de root

La demostración en Linux se basó en programas cBPF clásicos sin privilegios. Los investigadores entrenaron un predictor de saltos con un programa, lo liberaron y consiguieron que otro código compilado por JIT ocupara la misma memoria.

Después, atacaron un proceso su en ejecución y extrajeron de la memoria el hash de la contraseña de root. Según la información publicada sobre la investigación, en el escenario probado el ataque podía filtrar cualquier dato de la memoria en procesadores Intel modernos, incluso en sistemas totalmente actualizados que usaban la configuración de seguridad predeterminada.

El equipo desarrolló dos ataques cBPF completos. Uno funcionaba con la configuración predeterminada. El otro se adaptaba a sistemas con la ofuscación de constantes BPF activada, una defensa diseñada para evitar que las constantes controladas por el atacante aparezcan directamente en el código máquina generado.

En la segunda versión, los investigadores codificaron las instrucciones controladas por el atacante mediante desplazamientos de salto. Aun así, lograron recuperar el hash de la contraseña en menos de cinco minutos.

Obtener un hash no equivale a conseguir la contraseña en texto plano. El atacante tendría que descifrar el hash por separado, quizá con recursos informáticos locales o en la nube. El resultado dependería de la robustez de la contraseña y del algoritmo de hash.

La vía demostrada también requiere que el atacante pueda ejecutar programas cBPF sin privilegios. En el entorno descrito por los investigadores, las funciones JIT más avanzadas de eBPF requieren acceso privilegiado; cBPF, en cambio, sigue siendo relevante para seccomp, el filtrado de sockets y el filtrado de paquetes. Docker y Chrome son algunas de las aplicaciones que utilizan estas funciones.

No se han dado a conocer las versiones afectadas del kernel de Linux. Por tanto, los administradores no pueden determinar si están expuestos limitándose a comparar la versión instalada con una lista pública de versiones vulnerables.

Dos CVE cubren el reciclaje del JIT de BPF y el vaciado del predictor

Los cambios para Linux están asociados a CVE-2026-64507 y CVE-2026-64508. La información del NVD disponible no incluye puntuaciones CVSS, vectores, clasificaciones CWE ni intervalos de versiones afectadas.

CVE-2026-64507 aborda el refuerzo de las protecciones cuando están activas las mitigaciones contra Spectre v2. Al reutilizar memoria del JIT de BPF, el kernel ejecuta una barrera de predicción de saltos indirectos (IBPB) para impedir que las predicciones obsoletas se trasladen al código recién escrito.

La implementación descrita omite el vaciado si el despachador de BPF ya utiliza una secuencia retpoline. El cambio solo se aplica cuando está activo el JIT de BPF y está condicionado por CONFIG_BPF_JIT, de modo que los kernels compilados con CONFIG_BPF_JIT=n sigan compilándose correctamente.

CVE-2026-64508 se ocupa de la gestión de la memoria ejecutable por parte del asignador del JIT de BPF. El asignador agrupa programas pequeños en bloques de mayor tamaño y recicla el espacio a medida que se cargan y eliminan programas. Por ello, una predicción creada para un programa antiguo puede dirigir la ejecución especulativa hacia código nuevo ubicado en la misma dirección.

La medida de refuerzo asociada vacía los predictores de saltos indirectos antes de reutilizar esa memoria JIT. Según se ha informado, los desarrolladores de Linux implementaron una mitigación para x86 que activa IBPB en todos los núcleos del procesador cuando el código cBPF ocupa una región que antes contenía código BPF.

Las correcciones se han integrado en el kernel de Linux, pero no se conocen las versiones exactas que las incluyen. Con los datos disponibles, ninguno de los dos CVE tiene un estado confirmado en el catálogo de vulnerabilidades explotadas conocidas de CISA ni una fecha límite de remediación. Por tanto, el ataque de investigación demostrado no debe describirse como una explotación confirmada en entornos reales.

Firefox y GraalVM presentan otras superficies de ataque

BTR no se limita al JIT de BPF de Linux. Los investigadores también observaron comportamientos relevantes en el motor SpiderMonkey de Firefox y en Oracle GraalVM, aunque ninguno de los dos análisis culminó en un ataque completo de extremo a extremo.

En SpiderMonkey, las predicciones obsoletas persistían cuando se reutilizaban direcciones de código JIT en procesadores Intel. Los investigadores estimaron que una técnica completa podría filtrar decenas de bytes por segundo, pero sería necesario seguir trabajando para convertir la prueba de concepto en un ataque funcional contra el navegador.

El posible impacto depende, en parte, del aislamiento entre procesos. Según la información publicada por SecurityWeek sobre los hallazgos, Mozilla no aveva ancora completato l’implementazione dell’isolamento dei siti. In alcune circostanze, i contenuti di schede diverse potevano quindi condividere lo stesso spazio di indirizzamento, creando una possibile via per esporre dati tra schede. Non è stato segnalato alcun attacco completo che abbia dimostrato questo scenario.

En GraalVM, los investigadores encontraron una ruta especulativa que podía eludir una comprobación de sandbox basada en el enmascaramiento de memoria, en el modo de sandbox más estricto del entorno de ejecución. Lograron provocar la reutilización de direcciones de memoria de forma fiable, pero la actividad de compilación y recolección de basura eliminó las entradas obsoletas del predictor de saltos antes de que pudieran completar el ataque.

Esta interferencia limitó el experimento, pero no refuta la existencia de la primitiva. Los investigadores no la consideraron un obstáculo fundamental. Según se ha informado, Oracle ha implementado algunas mitigaciones, aunque no se han dado a conocer las versiones exactas de los productos ni los niveles de parche.

Las defensas de hardware elevan el coste, pero no cierran todas las vías

Las protecciones del flujo de control, como Indirect Branch Tracking de Intel y Branch Target Identification de Arm, pueden dificultar los ataques BTR. Sin embargo, no eliminan todas las técnicas descritas por los investigadores.

En los procesadores Intel más antiguos, las instrucciones pueden ejecutarse especulativamente antes de que se aplique la comprobación pertinente del flujo de control. Lion Cove fue la primera generación de Intel que, según los investigadores, no presenta esa condición de carrera específica.

Aun así, la ausencia de esa condición de carrera en IBT no implica una protección completa. Según se ha informado, los investigadores eludieron IBT en procesadores sin esa condición cuando la ofuscación de constantes estaba desactivada. Combinar IBT sin condición de carrera con la ofuscación de constantes ofrece una defensa mucho más sólida.

En general, los fabricantes de CPU han señalado que ya existen barreras como IBPB y han sostenido que el software debe vaciar el estado del predictor cuando cambia el significado de la memoria ejecutable. AMD afirmó que la investigación no había identificado una nueva vulnerabilidad en sus productos y remitió a los usuarios a las recomendaciones existentes sobre Spectre v2. No se han publicado las respuestas de Intel ni de Arm.

Los administradores deben priorizar las actualizaciones del kernel y del firmware

Los administradores de Linux deben instalar las últimas actualizaciones del kernel que ofrezca su distribución, especialmente en los sistemas donde se pueda acceder a cBPF sin privilegios. Como no se ha publicado una lista de versiones corregidas, los avisos de seguridad de cada distribución son la forma más práctica de identificar los paquetes actualizados.

También deben instalarse las actualizaciones de firmware y microcódigo. Estas pueden reforzar las protecciones existentes contra la ejecución especulativa, aunque la solución práctica descrita para el reciclaje de memoria BPF consiste en activar IBPB desde el software.

Los equipos deben revisar si sus cargas de trabajo necesitan cBPF sin privilegios, sobre todo en servidores multiusuario o sistemas que ejecutan código de usuarios menos confiables. Desactivar funciones sin conocer sus dependencias podría interrumpir el uso de seccomp o de los filtros, por lo que conviene probar cualquier restricción antes de aplicarla.

No se han dado a conocer indicadores de malware específicos del ataque, hashes de archivos, dominios ni firmas de red. La detección debe centrarse, por tanto, en el uso inusual de las funciones BPF locales, la carga inesperada de programas sin privilegios y la actividad sospechosa en torno a procesos sensibles. Estas señales no son exclusivas de BTR, pero pueden ayudar a identificar los requisitos previos utilizados en el ataque demostrado contra Linux.