Qué es GPU Rowhammer o GPUHammer y por qué pone en jaque a la IA

Última actualización: abril 8, 2026
Autor: Isaac
  • GPUHammer aplica la vulnerabilidad Rowhammer a memorias GDDR6 de GPU, provocando cambios de bit físicos que rompen el aislamiento de memoria.
  • En modelos como la NVIDIA RTX A6000, un único bit alterado puede reducir la precisión de redes neuronales profundas del 80 % al 0,1 % sin síntomas visibles.
  • Los ataques pueden escalar hasta acceso root en sistemas Linux, incluso con IOMMU activado, explotando tablas de páginas de GPU y fallos en controladores.
  • Las mitigaciones pasan por habilitar ECC y reforzar el aislamiento de dispositivos, asumiendo pérdidas de rendimiento y mayor complejidad en la gestión de la seguridad.

Qué es GPU Rowhammer

En los últimos años hemos aprendido que las vulnerabilidades de seguridad no solo afectan a programas o sistemas operativos: también golpean, y muy duro, al propio hardware. Ataques como Spectre, Meltdown o las distintas variantes de Rowhammer han demostrado que, cuando el problema está en el diseño físico de la memoria, los fallos pueden ser silenciosos, difíciles de detectar y con consecuencias enormes, por eso es útil detectar fallos de hardware.

Dentro de este panorama aparece GPUHammer, un ataque que traslada la idea de Rowhammer al mundo de las tarjetas gráficas. Hablamos de una técnica capaz de corromper la memoria GDDR6 de las GPU modernas de NVIDIA y hundir la precisión de modelos de inteligencia artificial hasta niveles ridículos, todo sin que el sistema se bloquee ni muestre errores evidentes. Y sí, con algo tan aparentemente inocente como cambiar un solo bit.

Qué es Rowhammer y por qué es tan peligroso

Rowhammer es una vulnerabilidad de hardware en memorias DRAM conocida desde 2014. Se basa en un fenómeno físico: si se accede de forma muy rápida y repetida (el famoso “martilleo” o hammering) a una fila concreta de memoria, se generan perturbaciones eléctricas que pueden provocar cambios de bit en las filas adyacentes. Un 0 puede convertirse en 1 o al revés, sin que haya un error de software de por medio.

En los primeros estudios, centrados en DDR3 y luego DDR4 y LPDDR4, se demostró que un atacante era capaz de utilizar este efecto para romper el aislamiento de memoria. Eso abría la puerta a escenarios muy serios: pasar de usuario sin privilegios a administrador, escapar de una sandbox o acceder a datos que se suponían protegidos simplemente forzando cambios de bit en posiciones muy concretas.

La esencia del ataque es que la memoria DRAM, a medida que se miniaturiza y sus celdas se colocan cada vez más juntas, se vuelve más sensible a fugas de carga y a interferencias eléctricas. Rowhammer explota precisamente esa fragilidad: repite accesos a unas filas objetivo hasta que algunas celdas cercanas pierden estabilidad y sus bits “se dan la vuelta” sin que el sistema lo espere.

Con el tiempo, los investigadores han ido encontrando variantes más agresivas y sofisticadas, como los ataques multidireccionales, donde se “golpea” una fila desde varias direcciones distintas para incrementar aún más la probabilidad de corrupción de datos. También han ido apareciendo mitigaciones como ECC o técnicas de refresco dirigido del tipo Target Row Refresh (TRR), aunque no siempre resultan infalibles.

Hasta hace poco, la mayor parte de la atención se centraba en la memoria de las CPUs, pero el enorme crecimiento de la IA y el uso masivo de GPUs discretas en centros de datos ha puesto la lupa también en la memoria gráfica GDDR (ver el estándar ClusterMax 2.0 en la nube de IA). Y ahí es donde entra GPUHammer.

Qué es GPUHammer: Rowhammer llevado a las GPU

GPUHammer es el nombre que se ha dado al primer ataque Rowhammer demostrado con éxito contra memoria GDDR6 de una GPU. Distintos equipos de investigación han logrado, de manera independiente, aplicar el concepto de martilleo de filas de DRAM a tarjetas gráficas modernas de NVIDIA basadas en arquitecturas como Ampere y Ada Lovelace.

En concreto, una parte clave de los trabajos se ha centrado en la NVIDIA RTX A6000, una GPU profesional con arquitectura Ampere y 48 GB de memoria GDDR6. Sobre este modelo se han desarrollado varias pruebas de concepto que muestran dos grandes líneas de ataque: por un lado, degradar brutalmente la precisión de modelos de aprendizaje automático; por otro, conseguir escaladas de privilegios hasta nivel kernel o incluso root en sistemas Linux.

La técnica GPUHammer demuestra que la memoria GDDR6 de la GPU es vulnerable a los mismos fenómenos físicos que afectan a la DRAM convencional, pese a que durante años se pensó que era poco práctico explotar Rowhammer en vídeo. La realidad es que, con suficiente ingeniería inversa, código CUDA de bajo nivel y acceso paralelo masivo, se pueden inducir cambios de bit también en estas memorias.

Lo que convierte a GPUHammer en una amenaza especialmente incómoda es que su objetivo no es solo leer datos ajenos, sino corromper silenciosamente la información crítica que se aloja en la memoria de la GPU: pesos de redes neuronales, tablas de páginas, estructuras del controlador, etc. El sistema sigue funcionando “normal”, pero los resultados ya no son de fiar.

  ¿Cuáles son las partes de la ventana?

Cómo funciona el ataque Rowhammer en memoria GDDR6

Adaptar Rowhammer a las GPU no ha sido precisamente un paseo. La memoria GDDR6 presenta varios obstáculos técnicos que históricamente se consideraban un freno para este tipo de ataques: latencias de acceso más altas (hasta cuatro veces mayores que DDR4), frecuencias de refresco superiores, una distribución física de celdas más compleja y la presencia de mecanismos propietarios de protección como TRR, poco documentados.

Para superar estas barreras, los investigadores han desarrollado técnicas específicas de ingeniería inversa sobre DRAM GDDR. Han analizado cómo CUDA mapea memoria virtual a física, han deducido la organización interna de bancos y filas de la GDDR6 y han diseñado patrones de acceso extremadamente optimizados que presionan justo donde hace falta, maximizando la tasa de activación de filas sin introducir latencias que delaten el ataque.

El ataque se basa en lanzar accesos masivos y paralelos desde la GPU, llegando a realizar centenares de miles de accesos simultáneos a filas concretas. Múltiples hilos y warps funcionan como un “martillo sincronizado” que golpea sin descanso las mismas celdas y genera perturbaciones en sus vecinas. Con el tiempo suficiente, comienzan a aparecer cambios de bit en posiciones controladas.

En uno de los estudios más destacados, se utilizaron varios modelos de IA preentrenados sobre ImageNet ejecutándose en una RTX A6000. Al modificar únicamente un bit en los pesos (en particular en exponentes FP16), la precisión top-1 de modelos que rondaban el 80 % cayó a un increíble 0,1 %. Es decir, el clasificador pasó de funcionar razonablemente bien a ser prácticamente inútil.

Otros equipos, como los de UNC Chapel Hill y Georgia Tech, han demostrado exploits a los que han bautizado como GDDRHammer y GeForge, capaces de modificar bits en la memoria GDDR6 de determinadas GPU de NVIDIA (por ejemplo, GeForce RTX 3060, RTX 6000 y RTX A6000) y, a partir de ahí, manipular estructuras clave como las tablas de páginas de la GPU para conseguir acceso de lectura/escritura arbitrario a memoria.

Modelos de GPU afectados y alcance de la vulnerabilidad

Hasta el momento, las pruebas de concepto de GPUHammer y ataques afines se han verificado sobre un conjunto concreto de tarjetas gráficas con memoria GDDR6. Entre los modelos confirmados se encuentran la ya mencionada NVIDIA RTX A6000 y GPUs como la GeForce RTX 3060 y la RTX 6000 para estaciones de trabajo, todas basadas en arquitecturas modernas como Ampere o Ada Lovelace.

NVIDIA ha reconocido la existencia del problema y lo ha relacionado con la memoria GDDR6 dedicada utilizada en estas tarjetas (y con factores de mercado como la escasez de RAM). Hay estudios que intentaron reproducir el ataque sobre otros modelos, como la RTX 3080, sin observar cambios de bits en las condiciones de prueba utilizadas. Se especula con que puedan influir diferencias en el proveedor de DRAM, características internas del chip o incluso cuestiones térmicas y de voltaje.

En el caso de GPUs con memoria HBM (High Bandwidth Memory), como la NVIDIA A100, los investigadores no encontraron fluctuaciones de bits bajo el mismo escenario de ataque, lo que sugiere que el diseño y empaquetado de HBM podría ofrecer una resistencia distinta frente a Rowhammer. Sin embargo, eso no garantiza que otros diseños de GDDR u otras generaciones no puedan llegar a ser vulnerables.

Conviene subrayar que, por ahora, el número de modelos en los que se ha demostrado el ataque es relativamente pequeño: tres GPUs comprometidas de forma clara, todas de NVIDIA. Pero los propios equipos de investigación reconocen que el ritmo académico va muy por detrás de la velocidad de lanzamiento de nuevo hardware, por lo que es razonable sospechar que otras generaciones, incluidas las de AMD o Intel, puedan compartir debilidades similares.

No obstante, hasta la fecha no se conocen casos documentados de explotación activa de estos ataques en entornos reales. La peligrosidad práctica es aún limitada, aunque el potencial de impacto es muy alto, especialmente en infraestructuras en la nube y servicios con múltiples inquilinos que comparten GPU.

Degradación de modelos de IA: cuando un bit lo arruina todo

Uno de los aspectos más llamativos de GPUHammer es su capacidad para destrozar la precisión de modelos de inteligencia artificial sin necesidad de tocar los datos de entrada ni el código del modelo. Todo ocurre a nivel de memoria de la GPU, alterando directamente los parámetros internos de la red neuronal.

En experimentos con modelos de clasificación de imágenes como ResNet-20 y otras arquitecturas entrenadas sobre ImageNet, los investigadores observaron que con apenas una inversión de bit en determinados pesos, sobre todo en exponentes FP16, la precisión top-1 podía pasar de alrededor del 80 % a un ridículo 0,1 %. En otros casos, la degradación osciló entre un 56 % y un 80 %, haciendo que el modelo dejase de ser fiable para cualquier uso serio.

Lo más inquietante es que este tipo de corrupción es completamente sigilosa a ojos del sistema operativo: la GPU sigue respondiendo, no hay cuelgues ni mensajes de error llamativos y las herramientas habituales de monitorización no detectan nada raro. Simplemente, la IA empieza a dar respuestas malísimas, y resulta muy difícil atribuirlo a una manipulación maliciosa de la memoria.

  ¿Dónde está el control parental?

En un escenario de GPU compartida, por ejemplo en un servicio de hosting de modelos abiertos o en un proveedor de infraestructura de GPU bajo demanda, un usuario sin privilegios de administrador podría intentar ejecutar GPUHammer desde su propio kernel CUDA para influir en los pesos de modelos que están utilizando otros clientes en la misma tarjeta, degradando su precisión sin necesidad de acceder directamente a sus datos.

Esto abre una superficie de ataque especialmente delicada para sectores donde la IA se emplea en aplicaciones críticas: diagnóstico médico, detección de fraude, sistemas de trading algorítmico, vehículos autónomos o plataformas de IA perimetral. Un modelo silenciosamente manipulado puede tomar decisiones peligrosas sin que nadie lo note hasta que el daño ya se ha producido.

Escalada de privilegios y compromisos del sistema

Más allá de corromper modelos de IA, algunas variantes de estos ataques Rowhammer sobre GPU, como GDDRHammer y GeForge, persiguen un objetivo aún más ambicioso: obtener el control total del sistema anfitrión. Para ello, los investigadores se centran en estructuras de memoria sensibles, como las tablas de páginas de la GPU y ciertos elementos del controlador de NVIDIA.

El mecanismo resumido es el siguiente: al lograr flips de bits en posiciones muy concretas de las tablas de páginas usadas por la GPU, un kernel CUDA sin privilegios puede obtener acceso de lectura/escritura arbitrario a regiones de memoria que originalmente no estaban a su alcance. Una vez conquistada la memoria de GPU, es posible encadenar esta capacidad con vulnerabilidades recientes en el controlador para llegar a la memoria de la CPU.

En pruebas sobre sistemas Linux, esta combinación ha permitido alcanzar acceso a nivel de kernel e incluso root, comprometiendo completamente la máquina. El resultado es un control total sobre el sistema del anfitrión: lectura, modificación y borrado de datos, instalación de malware persistente o desactivación de medidas de seguridad.

Lo especialmente preocupante es que este tipo de ataque puede funcionar incluso con ciertas mitigaciones activadas, como IOMMU (Unidad de Gestión de Memoria de Entrada/Salida), que se utiliza precisamente para restringir qué zonas de memoria puede ver cada dispositivo. Hay demostraciones de exploits funcionales contra la RTX A6000 que logran escalar privilegios aun con IOMMU habilitado por defecto en la BIOS.

En entornos multitenant, como plataformas de escritorio virtual (VDI) o nubes públicas que comparten GPU entre clientes, estas técnicas suponen un riesgo de aislamiento entre inquilinos que muchas arquitecturas de seguridad actuales no contemplan adecuadamente, ya que partían de la premisa de que la GPU era un mero acelerador “tonto” y no una vía de compromiso del host.

Mitigaciones propuestas: ECC, IOMMU y buenas prácticas

Tras la publicación de los distintos estudios, NVIDIA ha emitido advertencias a sus clientes y ha recomendado varias medidas de mitigación para reducir el riesgo de ataques tipo GPUHammer. La principal y más repetida es la activación del ECC (Error-Correcting Code) en la memoria de la GPU.

El ECC permite detectar y, en el caso de errores de un solo bit, corregir automáticamente las corrupciones en memoria. En el ecosistema NVIDIA, puede activarse a nivel de sistema mediante herramientas como nvidia-smi -e 1, y se puede comprobar su estado con los comandos de monitorización habituales. La propia compañía aconseja habilitar ECC en centros de datos y nodos que ejecuten cargas críticas de IA.

Sin embargo, esta medida tiene un coste nada despreciable: se ha medido una pérdida de rendimiento de alrededor de un 10 % en tareas de inferencia de aprendizaje automático y una reducción de la memoria útil disponible en torno al 6,25 %. En aplicaciones gráficas puramente visuales se han llegado a reportar caídas de rendimiento de hasta un 30 % al activar ECC.

Además, el ECC no es un escudo absoluto. Aunque ayuda con errores aislados de un bit, algunos ataques Rowhammer avanzados pueden provocar flips múltiples o patrones que consigan eludir la corrección de errores. Por eso los investigadores insisten en que, aunque sea una barrera importante, no puede considerarse una solución definitiva.

Otra recomendación extendida es revisar la configuración de la BIOS para asegurarse de que IOMMU está habilitado, de forma que las GPUs y otros dispositivos no puedan acceder libremente a todo el espacio de memoria del host. IOMMU asigna direcciones virtuales visibles para el dispositivo a direcciones físicas restringidas, ayudando a contener los daños.

Aun así, como se ha mencionado, existen pruebas de concepto que consiguen explotar vulnerabilidades incluso con IOMMU activo, por lo que esta protección debe verse como una capa más dentro de una estrategia de defensa en profundidad, y no como una garantía total. Complementariamente, NVIDIA aconseja monitorizar registros del sistema (como /var/log/syslog o dmesg) en busca de errores de memoria corregidos que puedan ser señal de intentos de explotación y, si procede, deshabilitar hardware inestable.

  ¿Qué pantallas son 3D?

Por último, en hardware más reciente como las GPUs NVIDIA H100 o RTX 5090, el ECC está integrado de forma más profunda en el propio chip, proporcionando una protección nativa más sólida frente a ataques de este estilo, aunque todavía no hay suficiente literatura pública que garantice su inmunidad total a todas las variantes de Rowhammer.

Impacto en la nube, LLMs y modelos compartidos

Si utilizas GPUs en local para jugar o para pequeños experimentos de IA, puede que todo esto te suene lejano, pero la película cambia en cuanto nos vamos a entornos de nube, data centers y servicios de hosting de modelos. Ahí es donde GPUHammer se vuelve realmente preocupante.

Las grandes plataformas de IA suelen ejecutar modelos de lenguaje grandes (LLMs) y redes neuronales profundas de todo tipo sobre GPU compartida entre múltiples clientes. En estos escenarios, un solo ataque exitoso podría sabotear modelos ajenos, reducir su precisión de manera brutal o incluso, en el peor de los casos, abrir la puerta a escalar privilegios y controlar el host.

Para los proveedores de infraestructura, activar ECC y otras medidas defensivas supone un trade-off entre seguridad, coste y rendimiento. Más protección implica GPUs más lentas y menos memoria efectiva por cliente, lo que incrementa los costes operativos y, previsiblemente, los precios de los servicios que llegan al usuario final.

Desde el punto de vista de las empresas que consumen GPUs en la nube para servir modelos abiertos o aplicaciones basadas en IA, el riesgo es que, si priorizan costes y rendimiento desactivando o relajando mitigaciones, sus servicios puedan empezar a responder de manera desastrosa sin que exista un fallo de software aparente. Y eso impacta directamente en la confianza de sus usuarios.

Conviene destacar que las nubes de primer nivel suelen contar con niveles de seguridad bastante más altos que un PC doméstico o un servidor casero, con políticas estrictas de aislamiento y monitorización. Aun así, GPUHammer es un toque de atención claro: la memoria de la GPU debe considerarse parte integral de la superficie de ataque global, no un detalle menor.

Relación con otras investigaciones: SpecHammer, CrowHammer y criptografía poscuántica

El interés en Rowhammer no se limita a las GPUs. A lo largo de la última década se han presentado variantes que combinan esta vulnerabilidad con otros vectores para lograr efectos todavía más sofisticados. Un ejemplo es SpecHammer, un ataque que fusiona Rowhammer con técnicas tipo Spectre de ejecución especulativa, permitiendo insertar valores maliciosos en memoria mediante cambios de bits y luego explotarlos a través de canales laterales.

Más recientemente ha surgido CrowHammer, una investigación centrada en el impacto de Rowhammer sobre algoritmos criptográficos poscuánticos. En particular, se ha demostrado que un único cambio de bit en ciertos parámetros internos del esquema de firma digital FALCON (FIPS 206), seleccionado por el NIST para estandarización, puede sesgar la salida lo suficiente como para reconstruir completamente la clave privada. Esto tiene implicaciones para la seguridad criptográfica.

Estos trabajos ponen de relieve que los ataques de cambio de bits no solo sirven para romper modelos de IA o escalar privilegios, sino que también pueden comprometer directamente algoritmos pensados para resistir la computación cuántica. Es decir, que la futura seguridad criptográfica podría venirse abajo si el hardware subyacente sigue siendo vulnerable a fenómenos como Rowhammer.

GPUHammer se encuadra en este contexto más amplio: una familia de ataques que no buscan tanto aprovechar bugs de software concretos como explotar efectos físicos inherentes al diseño de la memoria DRAM. Y eso hace que mitigarlos de forma definitiva sea un reto de largo recorrido que afecta tanto a fabricantes de chips como a diseñadores de sistemas y proveedores de servicios.

En este escenario, resulta cada vez más evidente que la seguridad de la IA, la criptografía avanzada y las infraestructuras críticas no puede abordarse solo desde el software: el hardware es ya un frente de batalla prioritario, y Rowhammer en todas sus variantes está demostrando hasta qué punto.

La aparición de GPUHammer ha dejado claro que las GPU modernas no son un simple acelerador inocuo, sino un componente clave cuya memoria puede ser manipulada para corromper modelos de IA, romper el aislamiento entre usuarios y hasta tomar el control del sistema anfitrión. Aunque por ahora los ataques demostrados son académicos y afectan a un número limitado de modelos, la combinación de cambios de bit silenciosos, pérdida masiva de precisión y posibles escaladas de privilegios es suficientemente seria como para que fabricantes, proveedores de nube y organizaciones que dependen de la IA tomen nota y empiecen a tratar la memoria de GPU como un elemento de seguridad de primer orden, aplicando ECC, aislamiento robusto y auditorías específicas si no quieren que un “simple” martilleo de filas en GDDR6 les acabe pasando factura.

cuánto durará la crisis de la DRAM por la demanda de la IA
Artículo relacionado:
Cuánto puede alargarse la crisis de DRAM por la IA