Fallo RDSEED en Zen 5 de AMD: impacto, modelos afectados y parches

Inicio » Windows » Fallo RDSEED en Zen 5 de AMD: impacto, modelos afectados y parches

Una confirmación oficial de AMD ha puesto el foco en un problema delicado: un fallo en la instrucción RDSEED que afecta a sus procesadores basados en la arquitectura Zen 5. Aunque no hablamos de ejecución remota ni de pérdida de rendimiento, sí impacta en la fiabilidad de la aleatoriedad por hardware, algo clave para cifrado, autenticación y otras tareas de seguridad. El corazón del asunto está en la calidad de los números aleatorios que produce el propio procesador, una pieza de confianza en múltiples capas del sistema.

¿Por qué importa? Porque algunos modos de RDSEED pueden devolver un valor que no debería pasar filtros de seguridad, y aun así lo señalan como correcto. AMD lo ha recogido en su boletín AMD-SB-7055 y lo ha catalogado como CVE-2025-62626 con severidad alta según CVSS 7.2. Ya hay mitigaciones y un calendario para microcódigo y AGESA, aunque variará según la familia de CPU y, en muchos casos, dependerá de cuándo publiquen BIOS los fabricantes.

Qué ha pasado exactamente y cómo ha salido a la luz

El equipo de AMD reconoce que las variantes de 16 y 32 bits de RDSEED pueden devolver el valor cero y, al mismo tiempo, marcar la operación como exitosa mediante el indicador CF a uno. Esta combinación rompe las expectativas de aleatoriedad garantizada, ya que un cero aceptado sin más puede degradar la entropía de semillas criptográficas y otros tokens sensibles.

La incidencia afloró públicamente a raíz de un reporte en la lista de correo del kernel de Linux, fuera del proceso interno de divulgación coordinada que AMD suele gestionar. A partir de ese momento la compañía confirmó el fallo y anunció la preparación de parches tanto en forma de microcódigo como de nuevos paquetes AGESA distribuidos a socios y fabricantes de placas.

Aunque el impacto en seguridad es serio, AMD precisa que no se trata de un vector de ejecución remota ni de un problema que penalice el rendimiento. La afectación se limita a la calidad estadística de la aleatoriedad, algo que, sin embargo, en entornos de seguridad importa y mucho.

RDSEED frente a RDRAND: qué hace cada una y por qué importa ahora

RDSEED es una instrucción de la ISA x86 diseñada para proporcionar números aleatorios con alta entropía, directamente del generador de ruido del procesador. Su razón de ser es nutrir de semillas criptográficas fiables a los sistemas que las necesitan, garantizando que la imprevisibilidad no se vea comprometida.

RDRAND, por su parte, está pensada para producir números pseudoaleatorios de forma muy rápida. Es útil en multitud de contextos, pero no sustituye la función de RDSEED cuando se quiere entropía más pura para iniciar generadores y construir claves robustas. De ahí que el bug actual sea relevante: afecta justo a la instrucción que entrega la materia prima más sensible para seguridad.

En el caso concreto de Zen 5, lo que falla son las variantes de 16 y 32 bits de RDSEED; la de 64 bits sigue comportándose correctamente. Esta distinción permite una salida temporal evidente: priorizar la ruta de 64 bits mientras llega el parche, evitando en lo posible los modos afectados.

Síntomas técnicos del bug en Zen 5 y su implicación criptográfica

El comportamiento que ha encendido las alarmas es concreto: RDSEED en 16 o 32 bits puede devolver 0 y reportar éxito con CF=1. Las implementaciones y librerías que confían ciegamente en que éxito implica un valor válido pueden consumir ese cero, degradando la entropía global sin darse cuenta.

Si bien hay software que ya reintenta cuando recibe valores que no encajan, otros caminos de código podrían no estar preparados para esta situación. El resultado puede ser una semilla menos impredecible para claves o protocolos, lo que reduce la resistencia frente a ataques estadísticos o de fuerza bruta en determinados escenarios.

Conviene subrayar de nuevo que la variante de 64 bits de RDSEED no está afectada. Usar 64 bits minimiza el riesgo mientras llega la solución definitiva, y es la recomendación principal de AMD para desarrolladores y fabricantes.

Qué CPU Zen 5 están afectadas (familias y modelos)

AMD ha acotado el problema a la familia Zen 5. Estas son las series que la compañía identifica como afectadas por la vulnerabilidad en los modos de 16 y 32 bits de RDSEED:

• AMD EPYC 9005 para servidores
• AMD Ryzen 9000 Desktop de sobremesa
• AMD Ryzen 9000HX para portátiles de alto rendimiento
• AMD Ryzen AI 300 con aceleración de IA
• AMD Ryzen AI Max 300 gama superior con NPU
• AMD Ryzen AI Z2 Extreme orientado a dispositivos portátiles
• AMD Ryzen Z2 Extreme para consolas y handhelds
• AMD Ryzen Threadripper 9000 entusiastas y creadores
• AMD Ryzen Threadripper PRO 9000 WX-Series workstations
• AMD EPYC Embedded 4005 plataformas embebidas
• AMD EPYC Embedded 9005 soluciones embebidas de alto rendimiento
• AMD Ryzen Embedded 9000 segmento embebido

Más allá de la lista, AMD ha dejado claro que el alcance se limita a Zen 5. Generaciones anteriores no están incluidas en este boletín concreto, y la edición de 64 bits de RDSEED se mantiene íntegra.

Cómo se comunicó y cuál es la posición oficial de AMD

El error se reportó en público a través de la lista del kernel de Linux, lo que precipitó la confirmación de AMD y la publicación de detalles técnicos. La compañía ha sido clara al describir la causa y el impacto y ha dado instrucciones provisionales para desarrolladores, administradores y fabricantes mientras preparan las correcciones.

AMD insiste en recomendaciones de uso prudente: evitar temporalmente los modos de 16 y 32 bits de RDSEED si se necesita entropía garantizada, apostar por 64 bits y, si procede, sustituir con fuentes de entropía por software hasta que esté instalado el microcódigo correspondiente.

Calendario de parches, microcódigo y AGESA

La compañía va a resolverlo mediante microcódigo y paquetes AGESA que después integrarán los fabricantes en BIOS o UEFI. La distribución será escalonada y variará por familia, con ventanas de publicación ya comunicadas por AMD:

• EPYC 9005 Turin: mitigación inicial disponible y segunda actualización prevista entre finales de octubre y mediados de noviembre de 2025; AMD concreta el 14 de noviembre para la versión AGESA TurinPI 1.0.0.8 en varias plataformas.
• Ryzen 9000, Ryzen AI 300 y Threadripper 9000: correcciones programadas para finales de noviembre; varios socios sitúan el despliegue alrededor del día 25.
• Ryzen Embedded y EPYC Embedded (incluidas EPYC Embedded 4005 y 9005, y Ryzen Embedded 9000): parches planificados para enero de 2026.

En el segmento de servidores ya hay una primera mitigación de microcódigo disponible para EPYC 9005, y AMD ha marcado el paso con una segunda ronda en noviembre. Para el mercado de consumo, la ventana es a finales de mes, mientras que los sistemas embebidos tendrán que esperar hasta principios de 2026.

AMD también apunta que las nuevas remesas de productos llegan ya con el problema solucionado. Se espera que los Ryzen 9000G aparezcan en tiendas con el parche aplicado, aunque no figuren explícitamente en el boletín de seguridad.

Como siempre, la publicación real en tu equipo dependerá de la cadena de distribución: fabricantes de placas, integradores y proveedores de servidores. Conviene vigilar la web de tu placa base para descargar BIOS actualizadas y, si usas Windows 11, actualizar tu PC con la última versión de Windows en las próximas semanas, con una referencia de plazos de unas tres semanas en muchos casos.

Medidas provisionales y buenas prácticas mientras llegan los parches

Mientras aterrizan las actualizaciones, hay una serie de acciones que ayudan a reducir la exposición. AMD y la comunidad han propuesto varias mitigaciones de bajo impacto que puedes aplicar según tu rol y tu entorno:

• Prioriza la variante RDSEED de 64 bits en todo código que lo permita, evitando las rutas de 16 y 32 bits.
• Si el diseño lo admite, usa fuentes de entropía por software de confianza para alimentar las semillas durante este periodo.
• Trata el valor 0 devuelto como un fallo temporal y repite la llamada hasta un resultado válido, evitando consumir ceros como válidos.
• En entornos Linux puedes desactivar la detección de la instrucción con el parámetro del kernel clearcpuid=rdseed si procede.

Para administradores, hay además medidas organizativas útiles. Limitar el acceso local y reforzar los privilegios minimiza las opciones de manipulación de entropía por parte de actores con presencia en el sistema.

En servicios críticos, la rotación de secretos tras la aplicación de parches es una opción a considerar. Regenerar claves o tokens sensibles consolida la vuelta a condiciones de entropía sanas, especialmente si hubo actividad criptográfica relevante durante el periodo afectado.

Impacto en empresas, nube y cargas sensibles

Donde más duele un fallo de este tipo es en entornos con generación masiva de claves, tokens y sesiones. La resistencia criptográfica depende de la calidad de la entropía, así que aceptar valores insuficientemente aleatorios incrementa la superficie de ataque.

Equipos de seguridad y operaciones deberían coordinarse para priorizar sistemas de alto riesgo: HSMs de software, plataformas de identidad, VPN, gestores de certificados o servicios que generan claves de manera automatizada. Cuanto antes se apliquen mitigaciones y parches, menor la ventana de exposición.

• Inventario: identifica nodos con Zen 5 en servidores, estaciones críticas y portátiles corporativos.
• Priorización: ordena sistemas que manejan datos sensibles o emiten claves con alta frecuencia.
• Pruebas: valida fuentes alternativas de entropía en laboratorio antes de pasar a producción.
• Rotación: planifica la renovación de credenciales críticas posparche en entornos de alto impacto.

Cómo de grave es de verdad: severidad alta, pero sin ejecución remota

El etiquetado de CVSS 7.2 sitúa el caso en severidad alta. No hay ejecución remota ni caída de rendimiento, lo que atenúa el riesgo respecto a otras familias de vulnerabilidades. Aun así, el afectado es un componente de confianza, y por eso requiere atención prioritaria.

La naturaleza local del vector, tal y como describe AMD, sugiere que un atacante con presencia en el equipo podría influir en los valores devueltos por RDSEED en 16 y 32 bits. Este matiz hace que el hardening del acceso local sea especialmente valioso hasta tener todo el parque actualizado.

Antecedentes y contexto: no es la primera vez que ocurre algo parecido

La industria ya se ha topado con contratiempos en generadores aleatorios por hardware. Intel afrontó en el pasado incidentes relacionados con RDSEED y RDRAND en algunas generaciones, que solventó con microcódigo, igual que está haciendo AMD ahora.

Este 2025 está siendo movidito para el ecosistema rojo. Hubo un fallo crítico en el módulo TPM que afectó a Ryzen 3000 a 9000 y se corrigió con actualizaciones, y poco después salieron a la luz problemas en la protección SEV-SNP de ciertos EPYC de tercera y cuarta generación que podrían permitir recuperar datos en virtualización avanzada.

Todo ello subraya un recordatorio recurrente: mantener la disciplina de actualización y auditoría en plataformas con seguridad por hardware es tan importante como parchear el sistema operativo o las aplicaciones.

Qué pueden esperar usuarios y desarrolladores en las próximas semanas

Si usas una placa base de consumo, ve comprobando el portal del fabricante para cuando aparezca la nueva BIOS con AGESA correspondiente. Muchos lanzamientos se están concentrando a finales de noviembre para Ryzen 9000, Ryzen AI 300 y Threadripper 9000, mientras que EPYC ha recibido mitigaciones tempranas y tiene otra tanda fechada en torno al 14 de noviembre.

Para quienes integran sistemas embebidos, la fecha de referencia se va a principios de 2026. EPYC Embedded 4005, EPYC Embedded 9005 y Ryzen Embedded 9000 figuran en la lista de espera hasta enero. Entre tanto, las mitigaciones de software y el uso de 64 bits en RDSEED son el mejor salvavidas.

Los desarrolladores deberían revisar cualquier dependencia explícita de RDSEED en 16 o 32 bits. Reencaminar llamadas a 64 bits, reintentar ante ceros y considerar fuentes de entropía auxiliares son decisiones pragmáticas que elevan la seguridad sin frenar proyectos.

También es buena idea documentar el cambio y, si aplica, planificar rotaciones de claves o tokens cuando el entorno retorne a condiciones de entropía plena tras instalar microcódigo y AGESA. Este gesto corta de raíz posibles dudas sobre material criptográfico generado durante el periodo afectado.

El panorama queda claro: la vulnerabilidad se limita a Zen 5 y a RDSEED en 16 y 32 bits, la edición de 64 bits es segura, hay parches en camino con fechas más o menos acotadas y existen mitigaciones útiles para no quedarse expuesto mientras tanto. Si seguimos las recomendaciones de AMD y de los fabricantes, el riesgo se mantiene controlado y la vuelta a la normalidad es cuestión de calendario.