El reinici no recupera l'aparell que guarda les teves còpies

El 2 de novembre Veeam va deixar al seu repositori el kernel que arregla una fallada amb 9,8 sobre 10 als seus aparells de còpies. El 4 va publicar un avís recomanant desactivar les actualitzacions automàtiques d'aquell mateix aparell. El 6, el document que explica el 9,8 i diu que la correcció arriba per l'actualitzador automàtic. Tres dates, una sola caixa. I entremig, una frase que pesa més que les altres: «A restart of the guest operating system does not recover the virtual machine.»

Tres dates i una sola caixa

El KB4966, del 6 de novembre, és el que documenta el CVE. CVE-2026-98432 és un ús després d'alliberar memòria en l'establiment de connexions TCP/IPv4 del kernel de Linux, amb CVSS 9,8. No és una fallada de Veeam: és una fallada del kernel que Veeam fica dins dels seus productes. La llista d'afectats és llarga —Veeam Software Appliance 13.1, Veeam Infrastructure Appliance 13.1, els aparells auxiliars Linux que despleguen Veeam Backup & Replication 13.1 i 12.3, el mitjà de recuperació de Veeam Agent for Linux, els aparells dels complements per a AWS, Google Cloud i Azure, i els workers que despleguen els complements per a hipervisors— i l'excepció explica el criteri millor que la llista: Kasten for Kubernetes no està afectat perquè «the container images do not include a Linux kernel». On hi ha kernel, hi ha fallada. El kernel corregit, 5.14.0-570.60.1+27.2.el9_6_ciq, és al repositori des del 2 de novembre i arriba per Veeam Updater; per al mitjà de recuperació de la 12.3, en canvi, el KB diu que la correcció privada «will be made available soon». Allà encara no hi ha res per instal·lar.

L'altre, el KB4960, és dos dies anterior —4 de novembre— i porta un títol sense adorns: «Veeam Software Appliance Fails to Boot with Kernel Panic on AMD EPYC Hosts.» A Veeam Software Appliance 13.1 i posteriors, l'arrencada s'atura amb aquest missatge:

La causa, en paraules del mateix KB: el kernel executa una prova de salut de jitterentropy en mode FIPS durant l'arrencada primerenca, i aquesta prova falla de manera intermitent en certs processadors AMD EPYC. I la frase que de debò marca la setmana: «a fix is currently not available for the kernel version used by the Veeam Software Appliance». No hi ha correcció per a la versió de kernel que fa servir l'aparell.

Aquest 9, i la línia que el converteix en un panic

El missatge no l'escriu Veeam: l'escriu el kernel. I com que l'aparell corre un 5.14.0-570 del llinatge Red Hat Enterprise Linux 9 —el sufix el9_6_ciq indica la compilació de CIQ—, hem anat a llegir aquell arbre i no el d'upstream. No diuen el mateix, i aquí hi ha el que interessa.

Comencem pel número. A crypto/jitterentropy.c d'aquell arbre només existeix un codi per a això, #define JENT_EHEALTH 9, amb el comentari «Health test failed during initialization». I la funció que decideix ocupa quatre línies:

Les dues proves de salut que exigeix la norma —la de recompte de repeticions i la de proporció adaptativa— desemboquen en el mateix 9. Així que el 9 diu que va fallar una prova de salut de la font d'entropia, i no diu quina. Si algú t'explica quina de les dues va ser, ho està deduint d'un arbre diferent del que arrenca el teu aparell: a l'actual d'upstream sí que hi ha un codi a part per a la prova de repeticions, però al de Red Hat 9 no existeix.

I ara el que de debò explica per què la màquina s'atura. A crypto/jitterentropy-kcapi.c, dins de jent_mod_init(), hi ha aquestes línies:

És la mateixa frase dues vegades, amb el mateix text i el mateix número, separades per un if. Amb fips_enabled, el kernel crida panic() i aquí s'acaba l'arrencada. Sense ell, escriu aquesta línia al registre, retorna -EFAULT i l'única cosa que passa és que un mòdul no carrega. Mateix amfitrió, mateixa fallada intermitent, mateix 9: el que decideix si tens un apunt al dmesg o una màquina a terra és una casella de compliment.

No és l'error de ningú. És exactament el que FIPS demana: si la font d'entropia no supera el seu autodiagnòstic, un sistema certificat no continua, i el comentari que encapçala aquestes línies —«Handle permanent health test error»— diu que qui ho va escriure ho tenia molt clar. Però val la pena saber que hi és, amb aquesta literalitat, al kernel que arrenca el servidor on viuen les teves còpies. És un control de compliment i continuïtat fent allò que se li va demanar. I és també el que et deixa la màquina a terra.

Els tres processadors de la llista són un de sol

El KB anomena tres models: AMD EPYC 7262, 7302 i 7F72. Vist així sembla una llista arbitrària. No ho és. El 7262 (8 nuclis) i el 7302 (16) es van llançar el 7 d'agost del 2019; el 7F72 (24 nuclis), el 14 d'abril del 2020. Els tres són EPYC de la sèrie 7002, nom en clau Rome, microarquitectura Zen 2. No són tres models solts: són una generació.

La lectura és nostra, no de Veeam: aquesta és la generació que va comprar qui va renovar maquinari el 2019 o el 2020 i encara no l'ha tornat a renovar. AMD no era llavors majoritària en servidors, així que no et direm que sigui mig parc; però és exactament el tipus d'amfitrió que continua en producció perquè funciona i ningú no ha tingut cap motiu per tocar-lo. I el matís honest en la direcció contrària, perquè també compta: el KB diu «including AMD EPYC 7262, 7302, and 7F72». Aquest «including» importa: la llista no és exhaustiva, que el teu no hi sigui no és cap certificat, i com que la prova falla de manera intermitent, que hagi arrencat bé les últimes deu vegades tampoc no ho és.

Això no és un problema d'arrencada: és de recuperació

Una arrencada que falla sempre es descobreix el dia que la toques. Una que falla de vegades es descobreix el dia que fa falta. I la màquina de què parlem és, per definició, la que s'encén quan ja ha passat alguna cosa: l'aparell que guarda l'última còpia.

Per això la frase del KB sobre el reinici importa tant. «Reiniciar el servidor de còpies» és, probablement, el pas que més vegades apareix escrit en un procediment de recuperació, i per a aquest mode de fallada concret és el pas equivocat: cal apagar la màquina virtual i tornar-la a encendre, i això no es fa des de dins. Es fa a l'hipervisor. Qui executi aquest pas a les tres de la matinada necessita permisos sobre l'amfitrió, no sobre l'aparell — i aquesta és una pregunta que es respon en trenta segons mirant la teva llista de guàrdia, i que gairebé ningú no ha fet. Quan vam repassar les dades de vuit-centes recuperacions alienes i els quatre casos que van fregar el seu RTO, el coll d'ampolla no era la còpia: era aixecar una sola font d'autenticació sana.

I hi ha un afectat a la llista del KB4966 que gairebé ningú no mira: el mitjà de recuperació de Veeam Agent for Linux. El suport amb què arrenques una màquina per restaurar-la porta el seu propi kernel de Linux, i per això és a la mateixa llista que l'aparell del qual restaures. Si alguna vegada t'has preguntat per què insistim a provar la restauració completa i no només a mirar que la feina surti en verd, la resposta és en aquesta ratlla.

Les dues instruccions que xoquen a la teva setmana

El KB4966 diu que la correcció del 9,8 arriba per Veeam Updater. El KB4960 recomana primer «redeploying the Veeam Software Appliance on a host with a different processor» i, si això no és possible, desactivar les actualitzacions automàtiques, instal·lar a mà i mirar la consola mentre reinicia. Totes dues coses són assenyades per separat. I hi ha un detall del KB4960 que les lliga: el panic apareix després d'un reinici, inclòs «a reboot that follows an update that installs a new kernel». El reinici que provoca la mateixa actualització és, per tant, un dels que poden acabar en panic. No és que el pedaç causi la fallada: és que per aplicar-lo cal passar per la porta on és.

El que no és damunt la taula és la tercera opció que qualsevol administrador de Linux donaria per feta: quedar-se al kernel anterior, fixar la versió, pedaçar per una altra via, mirar el dmesg amb calma. L'aparell està dissenyat perquè no puguis. Un sistema operatiu mínim endurit segons DISA STIG, amb SSH desactivat de fàbrica, sense accés de root i mantingut pel mateix fabricant. No és un descuit: és literalment la proposta de valor. Però significa que la latència de pedaç d'aquella màquina no la decideixes tu. I si el teu amfitrió és un dels tres models, avui no hi ha correcció per a la versió de kernel de l'aparell; és l'escenari exacte que vam descriure a la teva política de pedaços no contempla que no hi hagi pedaç.

Fa una setmana vam escriure sobre dos crítics de Veeam en 21 dies sense cap branca segura. Aquella vegada el codi era seu. Aquesta vegada la fallada és del kernel de Linux i la correcció també. El que és seu —i aquí hi ha la diferència que importa— és el calendari amb què t'arriben tots dos.

El que sí que compres amb un aparell tancat

No farem servir això per dir que el model és dolent, perquè no ho creiem. Muntem còpies gestionades amb Proxmox Backup Server i amb Veeam, amb la regla 3-2-1 i còpies immutables, i l'aparell tancat resol un problema que hem vist massa vegades: una configuració endurida que es degrada sola, mes a mes, a base d'excepcions raonables. Quan l'enduriment és una propietat versionada del producte i no una llista que algú manté a mà, aquesta degradació no passa.

El preu no és a la factura. Una part de la teva capacitat de reacció se'n va amb el model: no tries quan es pedaça el kernel, no tries quedar-te enrere, i quan apareix un mode de fallada com aquest el teu marge de maniobra és el que el fabricant hagi documentat. És un intercanvi perfectament legítim. El que no és legítim és signar-lo sense saber-ho i descobrir-ho el dia de l'incident.

Les quatre coses que miraríem aquesta setmana

1. Quin processador hi ha a sota. No el de l'aparell: el de l'amfitrió que l'executa. En un node Linux o Proxmox VE:

A vSphere, el model de processador surt al resum de l'amfitrió. Compara'l amb 7262, 7302 i 7F72. Si coincideix, el KB4960 t'està parlant a tu directament.

2. Quin kernel corre l'aparell avui. Es mira a Veeam Updater, que és la via per la qual arriba. La pregunta concreta és si el 5.14.0-570.60.1+27.2.el9_6_ciq del 2 de novembre ja hi és o encara és pendent. Si encara és pendent i a més estàs en un dels tres processadors, ja no és una tasca de manteniment: és una decisió, i convé que la prengui algú amb nom i cognoms.

3. Si la teva recuperació depèn que aquella màquina arrenqui. La regla 3-2-1, tal com la llegim nosaltres, no demana tres còpies per gust: demana que no comparteixin destí. Un panic lligat a un model de processador afecta qualsevol d'aquests aparells que corri sobre aquell amfitrió, així que si el repositori secundari viu al mateix maquinari, no són dues còpies: és la mateixa comptada dues vegades. La pregunta útil no és «tinc còpies?», sinó «puc llegir-ne alguna sense encendre aquell aparell?».

4. Què diu el teu procediment, paraula per paraula. Busca el pas on es recupera el servidor de còpies. Si diu «reiniciar», canvia-ho: per a aquesta fallada cal apagar i encendre la màquina virtual des de l'hipervisor. I escriu al costat qui de la guàrdia té permís per fer-ho. Són dues frases de canvi en un document i és l'única cosa d'aquesta llista que, el dia que calgui, es nota en minuts.

No hi ha res escandalós en aquest parell d'avisos. Un fabricant va trobar una fallada de kernel amb 9,8 i va publicar la correcció; un altre equip va documentar una fallada d'arrencada i va explicar el que sabia, inclòs que encara no hi ha solució. Totes dues coses són exactament el que un vol d'un fabricant. El que és incòmode no està als avisos: és que l'aparell que guarda la teva última còpia tingui aquesta setmana dues instruccions que estiren en direccions contràries i un mode de fallada que el teu procediment, escrit tal com està, no sap tractar.

Fonts (verificades el 09-11-2026): CVE-2026-98432 com a ús després d'alliberar en l'establiment de connexions TCP/IPv4 del kernel de Linux amb CVSS 9,8, la llista de productes afectats, 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 des del 2 de novembre del 2026, el lliurament per Veeam Updater i la frase sobre la correcció privada del mitjà de recuperació de la 12.3 («will be made available soon») — Veeam KB4966, publicat el 06-11-2026. El títol «Veeam Software Appliance Fails to Boot with Kernel Panic on AMD EPYC Hosts», el missatge literal del kernel panic, l'enumeració «including AMD EPYC 7262, 7302, and 7F72», la causa (prova de salut de jitterentropy en mode FIPS durant l'arrencada primerenca, amb fallada intermitent), l'abast «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» i les recomanacions (redesplegar en un amfitrió amb un altre processador; o desactivar les actualitzacions automàtiques, instal·lar a mà i vigilar el reinici) — Veeam KB4960, publicat el 04-11-2026; cobertura independent de l'avís — BleepingComputer, 06-11-2026. El codi del kernel l'hem llegit nosaltres a l'arbre de CentOS Stream 9, que és el llinatge del 5.14.0-570 de l'aparell: la definició única de JENT_EHEALTH amb valor 9 i la funció jent_health_failure() a crypto/jitterentropy.c, i el panic() condicionat a fips_enabled dins de jent_mod_init(), amb el seu pr_info i el seu return -EFAULT just a sota, a crypto/jitterentropy-kcapi.c. Hem comprovat també que aquell panic() no és a l'arbre 5.14 d'upstream i que l'arbre actual de Linus sí que defineix un codi a part per a la prova de repeticions. Generació, nombre de nuclis i dates de llançament dels tres EPYC (7262 i 7302, 7 d'agost del 2019; 7F72, 14 d'abril del 2020; tots tres sèrie 7002 Rome, Zen 2) — taules de la fitxa d'AMD EPYC. L'enduriment de l'aparell (sistema operatiu mínim segons DISA STIG, mantingut i actualitzat pel fabricant) és el que descriu el mateix fabricant, que l'anomena «Just Enough OS»; l'absència d'SSH i d'accés de root està documentada per integradors, no en aquella pàgina. La lectura que els tres processadors són una sola generació, l'observació sobre el mitjà de recuperació i les quatre comprovacions són elaboració nostra. Fotografia: sala de servidors de l'oficina del Servei Meteorològic Nacional dels Estats Units a Westampton (Nova Jersey), CC BY-SA 4.0 via Wikimedia Commons, retallada per nosaltres.