Un grupo de investigación ha propuesto una forma nueva de sabotear defensas usadas contra Spectre v2 en procesadores Intel y AMD. El punto clave es que un programa sin privilegios en Linux puede “timing” un hardware interrupt para caer justo en el hueco entre dos fases de la mitigación: cuando el procesador limpia el estado del predictor de ramas y antes de que el kernel lo use de nuevo. A esa técnica la bautizaron Interrupt Injection.
En pruebas realizadas en un sistema AMD Zen 2 con Linux, los investigadores lograron filtrar memoria arbitraria del kernel con alta precisión. Además, el método no requiere privilegios especiales: basta con ejecución local de código, lo que amplía el riesgo para entornos compartidos donde un atacante ya logró correr su programa.
Qué es Interrupt Injection y por qué funciona
Las mitigaciones típicas contra Spectre v2 se basan en una idea: el atacante no debería poder ejecutar código “en medio” de las operaciones que neutralizan y después consumen el estado del predictor de ramas. Dicho de otra forma, se espera que la ventana crítica sea atómica en la práctica, o al menos que no se intercale ejecución hostil entre la limpieza (sanitización) y el uso posterior.
Los investigadores argumentan que los interrupts rompen esa suposición. Los eventos de interrupción pueden dispararse en momentos muy cercanos a esas transiciones, y Linux permite que cualquier usuario programe interrupciones con gran granularidad temporal. Así, el flujo del kernel termina incluyendo, como parte del mecanismo defensivo, el camino de retorno desde la interrupción.
En Zen 2, describen que la ventana relevante es extremadamente corta: “dos instrucciones” equivalentes a seis bytes. Por tanto, la explotación depende de capturar el interrupt justo dentro de ese intervalo, ni antes ni después.
Cómo se reproduce el ataque en condiciones reales
Para aumentar sus probabilidades, el equipo aplicó varias técnicas. Una de ellas consiste en evictar los bytes de la caché (L1 y L2) usando el subproceso hermano (hyperthread), con el objetivo de ralentizar el proceso y ajustar el timing. También eligieron un tipo de llamada al sistema que les daba control sobre registros adicionales, lo que mejoró la ventana efectiva en sus pruebas.
Según los resultados, los interrupts caían dentro del intervalo crítico entre un 5% y 12% de las veces en escenarios generales. En un subconjunto con registros bajo control del atacante, esa proporción rondó el 2%.
Una vez que la interrupción cae en la ventana, el manejador de interrupción se convierte en la “pieza” que reentrena o vuelve a preparar el estado necesario: el equipo lo describe como un “training gadget” activado por el propio manejador. En ese punto, usan un mecanismo llamado Inception (CVE-2023-20569) para llenar el buffer de la pila de retorno con un objetivo elegido por el atacante.
La idea de fondo es que se aprovecha la interacción entre Spectre v2 y mecanismos de protección relacionados con Safe RET, aprovechando que el manejo del interrupt puede introducir actividad entre pasos que se diseñaron con otra suposición de control del flujo.
Resultados: filtración del kernel y precisión
El artículo recoge que, en una máquina AMD Zen 2 ejecutando Linux 6.14 y con todas las mitigaciones de Spectre v2 activadas por defecto, el ataque consiguió filtrar memoria arbitraria del kernel.
Con esos ajustes, la tasa de fuga fue reportada en 5,47 bytes por segundo con una 91,97% de precisión. Con ese nivel, el equipo afirma que en 5 de 10 intentos pudieron localizar y leer el contenido de /etc/shadow, que contiene hashes de contraseñas en sistemas Linux.
Este tipo de escenario es especialmente preocupante porque no se trata de un vector que requiera privilegios: el riesgo se desplaza hacia sistemas compartidos o multiusuario donde el atacante pudo lograr ejecución local.
Qué pasa en Intel: mitigación no considerada necesaria
Los investigadores también evaluaron el comportamiento en varias plataformas. En los ensayos descritos, el rendimiento de la técnica varió entre arquitecturas. En términos de “mispredictions” (predicciones erróneas), se observó actividad en tres de cuatro máquinas evaluadas, con tasas diferentes para cada una.
Por ejemplo, reportan valores de éxito de 0,75% en Zen 2, 0,22% en Intel Arrow Lake y 0,037% en Cascade Lake Refresh. Indican que Zen 4 no produjo mispredictions en ese test y que en Intel no se demostró un ataque completo de extremo a extremo en el experimento descrito.
Ahora bien, los autores señalan que “misprediction” es una condición necesaria, pero no suficiente. También sostienen que, con trabajo previo que ya mostraba la existencia de “disclosure gadgets” en kernels, un ataque final podría ser posible en Intel combinando su primitiva de Interrupt Injection con ese otro trabajo.
Respuesta de AMD e Intel: parches y estado de la mitigación
El equipo comunicó sus hallazgos a AMD e Intel el 5 de febrero. Según el reporte, AMD planea un parche de kernel, mientras que en el caso de MIT se indicó que ya existía uno que habría sido incorporado y que llegaría mediante una actualización normal del sistema.
Además, AMD publicó un boletín con el identificador AMD-SB-7061, titulado “Safe RET Interrupt Vulnerability”. En ese aviso se indica que procesadores Zen 1 hasta Zen 4 están afectados. El resumen señala que un atacante que ejecute código podría inyectar un interrupt en un momento preciso para interrumpir Safe RET, lo que potencialmente debilita esa protección y puede llevar a divulgación de información. También se menciona que el problema parece estar asociado con la implementación en Linux de la mitigación Safe RET.
Sin embargo, el boletín no aporta detalles operativos completos: no incluye versión de parche, commits específicos ni un CVE. Y ese detalle, de cara a administradores, complica comprobar rápidamente si una máquina concreta ya está protegida o si el arreglo aún no llegó.
En la parte de Intel, el reporte sostiene que Intel no considera necesaria una mitigación. La postura indicada es que la explotabilidad depende de múltiples factores y que la técnica estaría cubierta por guías existentes. Al contrastar una guía identificada en el texto, no se menciona explícitamente el papel de los interrupts.
Limitaciones prácticas: por qué la ventana importa
La clave de la defensa que se explota es el intervalo minúsculo entre “neutralización” y “uso”. Si el sistema logre bloquear o neutralizar de nuevo el estado en el camino correcto (por ejemplo, en eventos de interrupción), el atacante pierde la posibilidad de reentrenar el predictor en ese punto exacto.
Los autores proponen una solución consistente en una segunda neutralización al salir de una interrupción: es decir, aplicar la limpieza del buffer de retorno antes de ejecutar la instrucción de retorno correspondiente (por ejemplo, iret en ciertos caminos) o realizar una operación equivalente en procesadores Intel más recientes. En el texto se afirma que bloquear interrupciones durante el tiempo del hueco podría tener un costo de rendimiento, pero ese costo no se cuantifica en el documento.
Qué puede hacer un administrador hoy
Si gestionas sistemas Linux con CPU AMD afectadas, el primer paso es revisar el estado de mitigaciones reportadas por el sistema. El artículo menciona que existe información accesible a través de rutas como /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow, aunque en la comprobación realizada por los autores no se encontraba documentación que mencionara explícitamente interrupciones en esa referencia.
Para Intel, aunque se alegue que no hace falta mitigación, la realidad es que los mensajes públicos que se citan no brindan un “checklist” tan claro como para saber, de inmediato, qué combinaciones ya están cubiertas en cada kernel y versión.
Por ello, lo más sensato es aplicar actualizaciones del sistema y del kernel cuando estén disponibles, siguiendo los boletines del fabricante. En el reporte también se indica que MIT afirma haber enviado un arreglo ya incluido en actualizaciones normales, mientras que AMD trabaja con un parche que llega vía sus canales de distribución.
Próximos pasos: presentación y artefactos
El trabajo fue presentado en Black Hat USA y se espera su publicación en USENIX Security en Baltimore la semana siguiente al momento del reporte. Además, al 6 de agosto el repositorio de artefactos citado en el documento no estaba disponible públicamente.
Mientras tanto, la combinación de timing extremo, reentrenamiento del predictor y el uso de mecanismos como Safe RET e Inception deja una lección clara: proteger contra Spectre v2 no solo requiere neutralizar el estado en entradas y salidas “normales”, sino también considerar las rutas inducidas por interrupciones.
Conclusión
Interrupt Injection muestra cómo un atacante con ejecución local puede explotar el microespacio temporal entre pasos de mitigación contra Spectre v2. El método se apoya en el hecho de que los interruptos pueden introducir ejecución en el momento exacto que las defensas asumen que no ocurrirá, lo que permite reinyectar el estado del predictor y, en ciertos entornos, terminar filtrando datos del kernel.
La respuesta de la industria incluye parches para plataformas afectadas y comunicados específicos, pero el reporte subraya una dificultad práctica: sin versiones de parche, commits o CVE bien definidos, a veces es más difícil para los administradores confirmar el estado real de protección. Por eso, mantener el kernel actualizado y seguir los boletines del fabricante sigue siendo la medida más directa para reducir el riesgo.
Fuente: https://thehackernews.com/2026/08/new-interrupt-injection-attack-can.html
