El 6 de agosto de 2026, Greg Kroah-Hartman publicó de golpe tres versiones estables del kernel de Linux —6.18.43, 6.6.149 y 6.1.181— para tapar una misma grieta: CVE-2026-68480, un nuevo bypass de las defensas contra Spectre v2 al que sus descubridores del MIT bautizaron Interrupt Injection. No es un Spectre más: ataca directamente la mitigación Safe RET que Linux venía usando para frenar la familia de fugas especulativas en procesadores AMD. Si administrás un servidor compartido o corrés cargas de terceros, este es de los que se actualizan el mismo día.
Interrupt Injection (CVE-2026-68480) es una técnica de canal lateral especulativo, presentada por investigadores del MIT CSAIL, que evade la mitigación Safe RET del kernel Linux. Un proceso sin privilegios inyecta interrupciones de hardware con precisión de nanosegundos dentro de la ventana en que el procesador "limpia" el predictor de saltos, vuelve a envenenarlo y filtra memoria del kernel. Afecta a CPUs AMD Zen 1 a Zen 4 y se corrige actualizando el kernel.
¿Por qué este ataque rompe una defensa que ya existía?
Porque no rompe la criptografía ni un chequeo de permisos: rompe la suposición temporal sobre la que se apoya la defensa. Safe RET (parte de la mitigación de SRSO, Speculative Return Stack Overflow) neutraliza el predictor de saltos justo antes de un retorno para que el procesador no especule con datos envenenados. El problema es que entre ese "neutralizar" y el "usar" hay una ventana de pocos ciclos. Los investigadores la llamaron TONTOU (Time-of-Neutralization to Time-of-Use): si un atacante logra meter una interrupción de hardware exactamente en ese hueco, vuelve a entrenar el predictor después de la limpieza y antes de que el kernel lo use. En Zen 2 esa ventana mide dos instrucciones, seis bytes. Aterrizar ahí a mano parece imposible, y sin embargo los datos dicen otra cosa.
¿Qué CPUs están afectadas: solo AMD o también Intel?
El impacto demostrado es sobre AMD; en Intel la cosa queda en advertencia. Según el aviso de AMD (boletín AMD-SB-7061, publicado el 6 de agosto de 2026), están afectadas las microarquitecturas Zen 1 a Zen 4, con explotación reproducida en Zen 1 y Zen 2. En Intel los investigadores midieron mispredicciones pero no lograron una fuga completa de punta a punta.
- AMD Zen 1–4: vulnerables según AMD-SB-7061. El leak end-to-end se demostró sobre Zen 1 y Zen 2; Zen 3 y Zen 4 quedan indicados pero sin PoC público.
- Intel Arrow Lake: los investigadores del MIT observaron mispredicciones al 0,22%, pero sin exploit funcional sin sumar "disclosure gadgets" adicionales.
- Intel Cascade Lake Refresh: tasa aún más baja, 0,037%. Intel comunicó que no considera necesaria una mitigación.
Traducido: si tu servidor corre sobre AMD Zen, esto te toca directo. Si es Intel, el riesgo hoy es teórico, pero el mecanismo quedó demostrado y conviene parchear igual porque el fix del kernel es transversal.
¿Qué tan grave es en la práctica? El leak que midió el MIT
Es un leak lento pero real y confiable. Los investigadores de MIT CSAIL Daniël Trujillo y Mengjia Yan, que nombraron y divulgaron la técnica, reportaron sobre AMD Zen 2 una tasa de fuga de 5,47 bytes por segundo con 91,97% de precisión, y como prueba de concepto leyeron el archivo /etc/shadow (los hashes de contraseñas del sistema). Cinco bytes y medio por segundo suena poco hasta que recordás que una clave privada o un hash no ocupan más que unos cientos de bytes.
| Métrica (Zen 2) | Valor reportado por MIT CSAIL |
|---|---|
| Tasa de fuga | 5,47 bytes/segundo |
| Precisión de lectura | 91,97% |
| Ventana explotable | 2 instrucciones / 6 bytes |
| Tasa de "aterrizaje" de la interrupción | 5–12% de los intentos |
| PoC | lectura de /etc/shadow |
El requisito clave —y lo que define su perfil de riesgo— es que necesita ejecución de código local: no hay explotación remota. Nadie te va a vaciar el kernel desde internet con esto. El escenario que importa es otro: un usuario sin privilegios, un contenedor, una función o un VPS vecino que ya está corriendo código en la máquina y quiere escalar hacia memoria que no le corresponde.
¿Qué versiones de kernel corrigen la CVE-2026-68480?
La corrección llegó por el árbol estable el 6 de agosto de 2026 y toca varias ramas soportadas. El commit se titula, literalmente, "x86/bugs: Make Safe-RET robust against interrupt injection", firmado por Borislav Petkov (AMD) y David Kaplan. Los tres LTS del titular son los que la mayoría de los servidores debería mirar primero:
- 6.18.43 — rama estable actual.
- 6.6.149 — LTS muy usada en distribuciones recientes.
- 6.1.181 — LTS de larga vida, típica en servidores conservadores.
El mismo día Greg Kroah-Hartman empujó también las LTS más viejas 5.10.263 y 5.15.214, y la mainline 7.1.7. La divulgación coordinada arrancó el 5 de febrero de 2026, así que los vendors tuvieron seis meses de embargo antes del anuncio público.
¿Cómo verifico si mi servidor está afectado y cómo lo actualizo?
Empezá por dos comandos: uno te dice qué kernel corrés y el otro qué opina el propio kernel sobre esta clase de falla. Linux expone el estado de la mitigación SRSO en sysfs:
uname -r
cat /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflowEse archivo te dice si la mitigación está activa (Mitigation: Safe RET) o si el sistema se declara vulnerable. Compará tu uname -r contra las versiones parcheadas de tu rama. Para actualizar, lo de siempre según la distro, y reiniciar —un fix de kernel no aplica hasta el reboot—:
# Debian / Ubuntu
sudo apt update && sudo apt upgrade
sudo reboot
# RHEL / Rocky / Alma
sudo dnf upgrade kernel
sudo reboot- Confirmá la versión después del reboot: volvé a correr
uname -ry verificá que quedaste en la build parcheada de tu rama. - Si no podés reiniciar ya: priorizá los hosts donde corre código de terceros (multi-tenant, CI runners, funciones); ahí es donde "ejecución local" deja de ser una hipótesis.
- Kernel livepatch: si usás parcheo en caliente, revisá que el proveedor haya publicado el fix; igual conviene planificar el reboot para dejar todo consistente.
¿Qué implica esto para servidores en producción y entornos multi-tenant?
El verdadero blanco es la infraestructura donde conviven varios inquilinos sobre el mismo hardware. Un leak de memoria del kernel a 5 bytes por segundo es irrelevante en tu notebook, pero cambia de peso cuando el que corre el código malicioso es un contenedor vecino o un usuario de un plan compartido: la barrera entre "tu proceso" y "el kernel de todos" es justo la que este ataque erosiona. Es la misma lógica que vimos en Copy Fail (CVE-2026-31431), aquella falla donde bastaban cuatro bytes al page cache para volverse root: distintos mecanismos, misma conclusión operativa —las vulnerabilidades locales del kernel son críticas apenas dejás que alguien más ejecute código en tu máquina.
La lectura para quien administra infraestructura es concreta:
- El aislamiento por hardware no es gratis ni eterno: cada nueva variante de Spectre demuestra que la separación especulativa entre kernel y userspace se sigue rompiendo por los costados. Parchear el kernel es la única defensa práctica.
- Priorizá por microarquitectura: mapeá qué hosts corren AMD Zen y actualizalos primero; ahí el riesgo pasó de teórico a demostrado con lectura de
/etc/shadow. - El reboot es parte del parche: a diferencia de un update de userspace, acá no hay mitigación real hasta reiniciar. Planificá la ventana en vez de dejarlo "para después".
- Rotá secretos si tenías exposición: en máquinas donde código no confiable pudo correr durante el período de embargo, tratá las claves y hashes sensibles como potencialmente comprometidos y rotálos.
Preguntas frecuentes
¿Interrupt Injection se puede explotar de forma remota?
No. El ataque requiere ejecución de código local en la máquina objetivo; no hay explotación por red. El riesgo se concentra en sistemas donde corre código de terceros —hosting compartido, contenedores, CI, funciones.
¿Estoy afectado si mi servidor es Intel y no AMD?
El impacto demostrado es sobre AMD Zen 1–4. En Intel (Arrow Lake, Cascade Lake Refresh) los investigadores midieron mispredicciones muy bajas pero no lograron una fuga completa, e Intel comunicó que no considera necesaria una mitigación. Aun así, conviene aplicar el parche del kernel porque es transversal.
¿Cómo sé qué kernel tengo que instalar?
Identificá tu rama con uname -r y actualizá a la build parcheada correspondiente: 6.18.43, 6.6.149 o 6.1.181 para las ramas modernas, o 5.15.214 / 5.10.263 en LTS más viejas. Después del reboot, reconfirmá la versión.
¿Con parchear el kernel alcanza o hay que cambiar de CPU?
Alcanza con actualizar el kernel: el fix endurece la mitigación Safe RET para que la ventana de inyección deje de ser explotable. No hace falta reemplazar hardware.
¿Qué es exactamente la ventana TONTOU?
Es el intervalo entre el momento en que el procesador neutraliza el predictor de saltos (Time-of-Neutralization) y el momento en que el kernel lo usa (Time-of-Use). En Zen 2 son apenas dos instrucciones / seis bytes, y ahí es donde el atacante inserta la interrupción para re-envenenar el predictor.
En resumen
CVE-2026-68480 no es un Spectre exótico de laboratorio: tiene PoC leyendo /etc/shadow, un boletín de AMD y parches en seis ramas del kernel el mismo día. La acción de hoy es simple y no admite mucha demora: verificá uname -r y spec_rstack_overflow, actualizá a la build parcheada de tu rama, reiniciá, y en los hosts multi-tenant sobre AMD Zen, movelo al principio de la cola. Fuentes: The Hacker News, Linux Compatible y warp2search.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
