El reinicio no recupera el aparato que guarda tus copias

El 2 de noviembre Veeam dejó en su repositorio el kernel que arregla un fallo con 9,8 sobre 10 en sus aparatos de copias. El 4 publicó un aviso recomendando desactivar las actualizaciones automáticas de ese mismo aparato. El 6, el documento que explica el 9,8 y dice que el arreglo llega por el actualizador automático. Tres fechas, una sola caja. Y entre ellas, una frase que pesa más que las otras: «A restart of the guest operating system does not recover the virtual machine.»

Tres fechas y una sola caja

El KB4966, del 6 de noviembre, es el que documenta el CVE. CVE-2026-98432 es un uso después de liberar memoria en el establecimiento de conexiones TCP/IPv4 del kernel de Linux, con CVSS 9,8. No es un fallo de Veeam: es un fallo del kernel que Veeam mete dentro de sus productos. La lista de afectados es larga —Veeam Software Appliance 13.1, Veeam Infrastructure Appliance 13.1, los aparatos auxiliares Linux que despliegan Veeam Backup & Replication 13.1 y 12.3, el medio de recuperación de Veeam Agent for Linux, los aparatos de los complementos para AWS, Google Cloud y Azure, y los workers que despliegan los complementos para hipervisores— y la excepción explica el criterio mejor que la lista: Kasten for Kubernetes no está afectado porque «the container images do not include a Linux kernel». Donde hay kernel, hay fallo. El kernel corregido, 5.14.0-570.60.1+27.2.el9_6_ciq, está en el repositorio desde el 2 de noviembre y llega por Veeam Updater; para el medio de recuperación de la 12.3, en cambio, el KB dice que el arreglo privado «will be made available soon». Ahí todavía no hay nada que instalar.

El otro, el KB4960, es dos días anterior —4 de noviembre— y lleva un título sin adornos: «Veeam Software Appliance Fails to Boot with Kernel Panic on AMD EPYC Hosts.» En Veeam Software Appliance 13.1 y posteriores, el arranque se detiene con este mensaje:

La causa, en palabras del propio KB: el kernel ejecuta una prueba de salud de jitterentropy en modo FIPS durante el arranque temprano, y esa prueba falla de forma intermitente en ciertos procesadores AMD EPYC. Y la frase que de verdad marca la semana: «a fix is currently not available for the kernel version used by the Veeam Software Appliance». No hay arreglo para la versión de kernel que usa el aparato.

Ese 9, y la línea que lo convierte en un panic

El mensaje no lo escribe Veeam: lo escribe el kernel. Y como el aparato corre un 5.14.0-570 del linaje Red Hat Enterprise Linux 9 —el sufijo el9_6_ciq indica la compilación de CIQ—, hemos ido a leer ese árbol y no el de upstream. No dicen lo mismo, y ahí está lo interesante.

Empecemos por el número. En crypto/jitterentropy.c de ese árbol solo existe un código para esto, #define JENT_EHEALTH 9, con el comentario «Health test failed during initialization». Y la función que decide ocupa cuatro líneas:

Las dos pruebas de salud que exige la norma —la de conteo de repeticiones y la de proporción adaptativa— desembocan en el mismo 9. Así que el 9 dice que falló una prueba de salud de la fuente de entropía, y no dice cuál. Si alguien te cuenta cuál de las dos fue, lo está deduciendo de un árbol distinto del que arranca tu aparato: en el actual de upstream sí hay un código aparte para la prueba de repeticiones, pero en el de Red Hat 9 no existe.

Y ahora lo que de verdad explica por qué la máquina se para. En crypto/jitterentropy-kcapi.c, dentro de jent_mod_init(), están estas líneas:

Es la misma frase dos veces, con el mismo texto y el mismo número, separadas por un if. Con fips_enabled, el kernel llama a panic() y ahí se acaba el arranque. Sin él, escribe esa línea en el registro, devuelve -EFAULT y lo único que pasa es que un módulo no carga. Mismo anfitrión, mismo fallo intermitente, mismo 9: lo que decide si tienes un apunte en dmesg o una máquina abajo es una casilla de cumplimiento.

No es el error de nadie. Es exactamente lo que FIPS pide: si la fuente de entropía no supera su autodiagnóstico, un sistema certificado no sigue adelante, y el comentario que encabeza esas líneas —«Handle permanent health test error»— dice que quien lo escribió lo tenía muy claro. Pero merece la pena saber que está ahí, con esa literalidad, en el kernel que arranca el servidor donde viven tus copias. Es un control de cumplimiento y continuidad haciendo lo que se le pidió. Y es también el que te deja la máquina abajo.

Los tres procesadores de la lista son uno solo

El KB nombra tres modelos: AMD EPYC 7262, 7302 y 7F72. Visto así parece una lista arbitraria. No lo es. El 7262 (8 núcleos) y el 7302 (16) se lanzaron el 7 de agosto de 2019; el 7F72 (24 núcleos), el 14 de abril de 2020. Los tres son EPYC de la serie 7002, nombre en clave Rome, microarquitectura Zen 2. No son tres modelos sueltos: son una generación.

La lectura es nuestra, no de Veeam: esa es la generación que compró quien renovó hierro en 2019 o 2020 y todavía no ha vuelto a renovarlo. AMD no era entonces mayoritaria en servidores, así que no vamos a decirte que sea medio parque; pero es exactamente el tipo de anfitrión que sigue en producción porque funciona y nadie ha tenido motivo para tocarlo. Y el matiz honesto en la dirección contraria, porque también cuenta: el KB dice «including AMD EPYC 7262, 7302, and 7F72». Ese «including» importa: la lista no es exhaustiva, que el tuyo no esté en ella no es un certificado, y como la prueba falla de forma intermitente, que haya arrancado bien las últimas diez veces tampoco lo es.

Esto no es un problema de arranque: es de recuperación

Un arranque que falla siempre se descubre el día que lo tocas. Uno que falla a veces se descubre el día que hace falta. Y la máquina de la que hablamos es, por definición, la que se enciende cuando ya ha pasado algo: el aparato que guarda la última copia.

Por eso la frase del KB sobre el reinicio importa tanto. «Reiniciar el servidor de copias» es, probablemente, el paso que más veces aparece escrito en un procedimiento de recuperación, y para este modo de fallo concreto es el paso equivocado: hay que apagar la máquina virtual y volver a encenderla, y eso no se hace desde dentro. Se hace en el hipervisor. Quien ejecute ese paso a las tres de la madrugada necesita permisos sobre el anfitrión, no sobre el aparato — y esa es una pregunta que se responde en treinta segundos mirando tu lista de guardia, y que casi nadie ha hecho. Cuando repasamos los datos de ochocientas recuperaciones ajenas y los cuatro casos que rozaron su RTO, el cuello de botella no era la copia: era levantar una sola fuente de autenticación sana.

Y hay un afectado en la lista del KB4966 que casi nadie mira: el medio de recuperación de Veeam Agent for Linux. El soporte con el que arrancas una máquina para restaurarla lleva su propio kernel de Linux, y por eso está en la misma lista que el aparato del que restauras. Si alguna vez te has preguntado por qué insistimos en probar la restauración completa y no solo en mirar que el trabajo salga en verde, la respuesta está en ese renglón.

Las dos instrucciones que chocan en tu semana

El KB4966 dice que el arreglo del 9,8 llega por Veeam Updater. El KB4960 recomienda primero «redeploying the Veeam Software Appliance on a host with a different processor» y, si eso no es posible, desactivar las actualizaciones automáticas, instalar a mano y mirar la consola mientras reinicia. Las dos cosas son sensatas por separado. Y hay un detalle del KB4960 que las ata: el panic aparece tras un reinicio, incluido «a reboot that follows an update that installs a new kernel». El reinicio que provoca la propia actualización es, por tanto, uno de los que pueden acabar en panic. No es que el parche cause el fallo: es que para aplicarlo hay que pasar por la puerta donde está.

Lo que no está sobre la mesa es la tercera opción que cualquier administrador de Linux daría por hecha: quedarse en el kernel anterior, fijar la versión, parchear por otra vía, mirar el dmesg con calma. El aparato está diseñado para que no puedas. Un sistema operativo mínimo endurecido según DISA STIG, con SSH desactivado de fábrica, sin acceso de root y mantenido por el propio fabricante. No es un descuido: es literalmente la propuesta de valor. Pero significa que la latencia de parche de esa máquina no la decides tú. Y si tu anfitrión es uno de los tres modelos, hoy no hay arreglo para la versión de kernel del aparato; es el escenario exacto que describimos en tu política de parcheo no contempla que no haya parche.

Hace una semana escribimos sobre dos críticos de Veeam en 21 días sin ninguna rama a salvo. Aquella vez el código era suyo. Esta vez el fallo es del kernel de Linux y el arreglo también. Lo que es suyo —y ahí está la diferencia que importa— es el calendario con el que te llegan los dos.

Lo que sí compras con un aparato cerrado

No vamos a usar esto para decir que el modelo es malo, porque no lo creemos. Montamos copias gestionadas con Proxmox Backup Server y con Veeam, con la regla 3-2-1 y copias inmutables, y el aparato cerrado resuelve un problema que hemos visto demasiadas veces: una configuración endurecida que se degrada sola, mes a mes, a base de excepciones razonables. Cuando el endurecimiento es una propiedad versionada del producto y no una lista que alguien mantiene a mano, esa degradación no ocurre.

El precio no está en la factura. Una parte de tu capacidad de reacción se va con el modelo: no eliges cuándo se parchea el kernel, no eliges quedarte atrás, y cuando aparece un modo de fallo como este tu margen de maniobra es el que el fabricante haya documentado. Es un intercambio perfectamente legítimo. Lo que no es legítimo es firmarlo sin saberlo y descubrirlo el día del incidente.

Las cuatro cosas que miraríamos esta semana

1. Qué procesador hay debajo. No el del aparato: el del anfitrión que lo ejecuta. En un nodo Linux o Proxmox VE:

En vSphere, el modelo de procesador sale en el resumen del anfitrión. Compáralo con 7262, 7302 y 7F72. Si coincide, el KB4960 te está hablando a ti directamente.

2. Qué kernel corre el aparato hoy. Se mira en Veeam Updater, que es la vía por la que llega. La pregunta concreta es si el 5.14.0-570.60.1+27.2.el9_6_ciq del 2 de noviembre ya está puesto o sigue pendiente. Si sigue pendiente y además estás en uno de los tres procesadores, ya no es una tarea de mantenimiento: es una decisión, y conviene que la tome alguien con nombre y apellidos.

3. Si tu recuperación depende de que esa máquina arranque. La regla 3-2-1, tal como la leemos nosotros, no pide tres copias por gusto: pide que no compartan destino. Un panic ligado a un modelo de procesador afecta a cualquiera de estos aparatos que corra sobre ese anfitrión, así que si el repositorio secundario vive en el mismo hierro, no son dos copias: es la misma contada dos veces. La pregunta útil no es «¿tengo copias?», sino «¿puedo leer alguna de ellas sin encender ese aparato?».

4. Qué dice tu procedimiento, palabra por palabra. Busca el paso donde se recupera el servidor de copias. Si dice «reiniciar», cámbialo: para este fallo hay que apagar y encender la máquina virtual desde el hipervisor. Y escribe al lado quién de la guardia tiene permiso para hacerlo. Son dos frases de cambio en un documento y es lo único de esta lista que, el día que haga falta, se nota en minutos.

No hay nada escandaloso en este par de avisos. Un fabricante encontró un fallo de kernel con 9,8 y publicó el arreglo; otro equipo documentó un fallo de arranque y contó lo que sabía, incluido que todavía no hay solución. Las dos cosas son exactamente lo que uno quiere de un fabricante. Lo incómodo no está en los avisos: está en que el aparato que guarda tu última copia tenga esta semana dos instrucciones que tiran en direcciones contrarias y un modo de fallo que tu procedimiento, escrito tal como está, no sabe tratar.

Fuentes (verificadas el 09-11-2026): CVE-2026-98432 como uso después de liberar en el establecimiento de conexiones TCP/IPv4 del kernel de Linux con CVSS 9,8, la lista de productos afectados, la frase sobre Kasten («the container images do not include a Linux kernel»), el kernel 5.14.0-570.60.1+27.2.el9_6_ciq disponible desde el 2 de noviembre de 2026, la entrega por Veeam Updater y la frase sobre el arreglo privado del medio de recuperación de la 12.3 («will be made available soon») — Veeam KB4966, publicado el 06-11-2026. El título «Veeam Software Appliance Fails to Boot with Kernel Panic on AMD EPYC Hosts», el mensaje literal del kernel panic, la enumeración «including AMD EPYC 7262, 7302, and 7F72», la causa (prueba de salud de jitterentropy en modo FIPS durante el arranque temprano, con fallo intermitente), el alcance «13.1 and later», la frase «a fix is currently not available for the kernel version used by the Veeam Software Appliance», la frase «a restart of the guest operating system does not recover the virtual machine» y las recomendaciones (redesplegar en un anfitrión con otro procesador; o desactivar las actualizaciones automáticas, instalar a mano y vigilar el reinicio) — Veeam KB4960, publicado el 04-11-2026; cobertura independiente del aviso — BleepingComputer, 06-11-2026. El código del kernel lo hemos leído nosotros en el árbol de CentOS Stream 9, que es el linaje del 5.14.0-570 del aparato: la definición única de JENT_EHEALTH con valor 9 y la función jent_health_failure() en crypto/jitterentropy.c, y el panic() condicionado a fips_enabled dentro de jent_mod_init(), con su pr_info y su return -EFAULT justo debajo, en crypto/jitterentropy-kcapi.c. Hemos comprobado también que ese panic() no está en el árbol 5.14 de upstream y que el árbol actual de Linus sí define un código aparte para la prueba de repeticiones. Generación, número de núcleos y fechas de lanzamiento de los tres EPYC (7262 y 7302, 7 de agosto de 2019; 7F72, 14 de abril de 2020; los tres serie 7002 Rome, Zen 2) — tablas de la ficha de AMD EPYC. El endurecimiento del aparato (sistema operativo mínimo según DISA STIG, mantenido y actualizado por el fabricante) es el que describe el propio fabricante, que lo llama «Just Enough OS»; la ausencia de SSH y de acceso de root está documentada por integradores, no en esa página. La lectura de que los tres procesadores son una sola generación, la observación sobre el medio de recuperación y las cuatro comprobaciones son elaboración nuestra. Fotografía: sala de servidores de la oficina del Servicio Meteorológico Nacional de Estados Unidos en Westampton (Nueva Jersey), CC BY-SA 4.0 vía Wikimedia Commons, recortada por nosotros.