Feedback su un'operazione di correzione condotta in una settimana sull'intero nostro parco KVM, secondo una strategia di patching il cui obiettivo centrale era di minimizzare l'impatto sui servizi dei nostri clienti.

Vulnerabilità nel sottosistema di virtualizzazione

Il martedì 7 luglio, all'inizio del pomeriggio, è stato segnalato un allarme di sicurezza relativo al CVE-2026-53359, una vulnerabilità di tipo use-after-free che interessa il sottosistema di shadow-paging di KVM x86 nel kernel Linux. La falla, risalente a diversi anni fa, viene resa pubblica il 6 luglio; blog di altri provider cloud appaiono già il 7.

KVM è il motore di virtualizzazione su cui si basa la stragrande maggioranza delle istanze ospitate da OVHcloud. Il meccanismo è il seguente: quando si verifica una modifica esterna di una Page Directory Entry (PDE), la voce RMAP può mantenere un riferimento a una pagina di memoria già liberata. Il kernel dereferenzia quindi quella pagina obsoleta, il che può causare un crash dell'hypervisor o, nello scenario peggiore, un innalzamento dei privilegi lato host. L'exploit è riproducibile: un test interno su un host non patchato causa un crash in circa due minuti.

Sono interessati tutti i nuclei Linux x86 precedenti il commit del patch, senza distinzione di distribuzione. Il patch ufficiale è backportato sui nostri nuclei di produzione Debian.

3 rischi principali vanno considerati:

• Un client VPS utilizza l'exploit per crashare l'host che fa funzionare la sua macchina virtuale: crash e reboot non controllato di diverse centinaia di macchine virtuali client.
• Scenario identico sulle istanze del Public Cloud, l'impatto è simile ma il numero di macchine virtuali per host è più limitato e le macchine virtuali sono più potenti e utilizzate per sistemi più sensibili (database, gestore di code, load balancer, ecc.). Questi sistemi sono spesso utilizzati in architetture applicative complesse con dipendenze complesse.
• Probabilità della futura pubblicazione di un exploit di presa di controllo dell'host, che aumenterebbe immediatamente il livello di rischio a un livello inaccettabile a causa dell'impatto sulla riservatezza dei dati dei clienti e sull'integrità dell'infrastruttura.

Per OVHcloud, il perimetro rappresenta decine di migliaia di server host hypervisor, che ospitano circa un milione di macchine virtuali. La domanda quindi non è stabilire se è necessario patchare, ma come condurre questa operazione su una tale scala, sapendo che un impatto cliente zero non è raggiungibile.

Opzioni sul tavolo per mitigare il rischio

1 : Aspettare i nuclei ufficiali patchati

Questa opzione ci rendeva dipendenti da un'agenda di terzi che ci lasciava in uno stato di rischio per un periodo non controllato. L'abbiamo scartata rapidamente rispetto al rischio.

2. Live Patch

Applicare un live patch richiede di autorizzare questo tipo di operazione nella configurazione del kernel, il che consente, per costruzione, di poter modificare il suo comportamento in volo, portando allo stesso tempo a una riduzione del suo livello di irrigidimento, limitando le capacità di rilevamento in caso di compromissione dello stesso. Inoltre, il live patch è una procedura sensibile per natura, che può portare a uno stato instabile su scala del parco. Si tratta di un'opzione che consente di risparmiare tempo in attesa di una soluzione permanente. Abbiamo deciso di non fare questo compromesso che avrebbe aumentato molto fortemente il rischio in caso di pubblicazione di exploit di presa di controllo dell'host.

3. Mitigazione tramite disattivazione della virtualizzazione nidificata

Disattivando la virtualizzazione nidificata sugli host si può rendere l'exploit inoperante. Non abbiamo visibilità sull'utilizzo di questa funzionalità da parte dei nostri clienti, quindi non è possibile determinare l'impatto sui servizi dei clienti, e questa funzionalità è necessaria per mantenere la capacità di migrazione live da un'istanza di un host fisico a un altro. Escludiamo questa possibilità rapidamente.

4. Live Migrate

Organizzare la migrazione live delle macchine virtuali, dagli host vulnerabili agli host vuoti che sono stati aggiornati nel frattempo. Questa opzione è molto soddisfacente in termini di continuità del servizio, poiché la migrazione viene eseguita senza alcun impatto sulle macchine virtuali, ad eccezione di una riduzione delle prestazioni durante la migrazione. Questa opzione richiede molto tempo, a causa della copia delle macchine virtuali da host a host; non è realisticamente utilizzabile su vasta scala e non è in linea con la volontà di proteggere i nostri clienti in pochi giorni anziché in diversi mesi. Abbiamo deciso di mantenere questa opzione solo per alcune macchine virtuali critiche, poiché ogni migrazione live provoca un notevole ritardo nell'esecuzione dei batch.

5. Backport del patch sui nostri nuclei e reboot di tutti gli host

Alla fine sarà questa l'opzione scelta e che verrà descritta in dettaglio nel seguito dell'articolo.

Martedì pomeriggio: attivazione e organizzazione della cellula di crisi

Non appena viene confermata la vulnerabilità, la priorità è quella di costruire una risposta strutturata e coordinata; gli analisti responsabili di questa prima analisi comprendono molto rapidamente le sfide degli giorni a venire. Le informazioni vengono diffuse internamente all'inizio del pomeriggio. Sono aperti diversi spazi di coordinamento: uno per il coordinamento tecnico, uno per il coordinamento della crisi, uno per le operazioni USA, uno per la comunicazione con i clienti e il supporto. Nel contempo, i team Kernel preparano e backportano il patch; il primo kernel corretto viene consegnato la sera.

I test di validazione vengono eseguiti in un ambiente di test la sera. Il patch è confermato, l'exploit non crasha più gli hypervisor patchati e i test di QA passano con il kernel patchato.

La cellula di crisi si evolve verso un monitoraggio del dispiegamento e viene quindi gestita dal NOC (Network Operations Center), che assume il ruolo di coordinatore operativo: monitoraggio del progresso globale, arbitraggio delle priorità tra regioni e servizi, mantenimento della visione d'insieme. L'esecuzione è gestita da esperti in Public Cloud e VPS, che eseguono i reboot, il live-migrate e le restrizioni di anti-affinità. La separazione tra coordinamento ed esecuzione è volontaria: il NOC coordina, i team operativi agiscono e riportano le metriche e gli eventi tecnici necessari al coordinamento.

La sincronizzazione con il Supporto Clienti (stato di avanzamento in tempo reale per rispondere ai clienti interessati) e i team di Sicurezza (monitoraggio della vulnerabilità, validazione del perimetro e dei criteri di fine operazione) è garantita in modo continuativo.

Poiché l'operazione segue il principio del follow the sun, la cellula funziona in 24/7 con una rotazione per area geografica. Ogni giorno vengono effettuati tre punti di sincronizzazione che coprono le transizioni di zona. Questi riuniscono NOC, esperti operativi, Supporto e Sicurezza per: condividere lo stato di avanzamento per regione, passare il testimone tra le zone (cosa ha funzionato, adeguamenti delle procedure sulla base dei feedback dal campo), e arbitrare le priorità della prossima sequenza.

La cellula completa riunisce, attraverso la rotazione 24/7: i team Kernel & Virtualization (analisi della correzione, backport, validazione), VPS e Public Cloud (implementazione), NOC (gestione), Run & SRE (orchestrazione, anti-affinità, live migration), Datacenter Operations (interventi hardware), Supporto client (richieste dei clienti), Sicurezza (vigilanza, perimetro, fine dell'operazione) e Comunicazione (trasparenza, notifiche mirate).

L'obiettivo assegnato è chiaro: patchare e riavviare gli host interessati il più rapidamente possibile al fine di ridurre la finestra di vulnerabilità, minimizzando l'impatto sui servizi. Il principale vincolo riguarda la scala: decine di migliaia di macchine da elaborare, su tutti i continenti, sapendo che una gestione caso per caso è materialmente impossibile a questo volume.

Il rischio principale in questa fase è lo sfruttamento della vulnerabilità, che porta a un crash dell'host non corretto. La cellula di crisi decide di applicare il patch globalmente a monte della fase di riavvio. In caso di sfruttamento della vulnerabilità, il crash di un host comporterà il suo riavvio e l'applicazione automatica del patch. Inoltre, esiste il rischio che la CVE venga sfruttata per un controllo malevolo dell'host. Non è disponibile pubblicamente alcun codice di exploit, ma sappiamo che è solo questione di tempo prima che un ricercatore riesca a sfruttare la vulnerabilità per ottenere il controllo dell'host. Poiché lo scenario è catastrofico, sappiamo che ogni minuto conta.

Una decisione assunta: un patching unilaterale ad impatto controllato

Il Comitato Esecutivo approva il Go/No-Go in serata: la prima regione verrà elaborata la mattina successiva. Per questo numero di macchine, non esiste uno scenario senza impatto. Negoziare una finestra di manutenzione con ogni cliente, verificare ogni dipendenza, orchestrare ogni riavvio su misura: tutte fasi materialmente incompatibili con un tempo accettabile rispetto al rischio di sicurezza.

La cellula di crisi prende quindi una decisione consapevole: un patching unilaterale a impatto controllato, applicato senza attendere l'accordo individuale di ogni cliente, sapendo che alcuni servizi subiranno un'interruzione. La motivazione si basa su tre punti:

• non patchare espone l'intero parco a una vulnerabilità di alta gravità;
• un trattamento caso per caso allungherebbe i tempi e lascerebbe la maggior parte degli ospiti vulnerabili per settimane;
• un'azione rapida e globale protegge il maggior numero di persone, anche a costo di impattare temporaneamente una minoranza.

La priorità non è più evitare l'impatto, ma minimizzarlo, diluirlo e renderlo prevedibile. È questa la linea che struttura l'intera operazione: follow the sun, priorizzazione delle regioni e pianificazione anti-affinità.

Mercoledì 8 luglio: partenza da Sydney

La scelta di Sydney per testare il deployment è banale: il numero di host è limitato e la fascia di deployment in HNO locale (durante la notte) corrisponde agli orari di ufficio dei team in Europa. Iniziare dalla regione più orientale consente di:

• operare sulla zona meno congestionata;
• convalidare il processo in condizioni reali, su scala ridotta, prima dell’industrializzazione;
• raccogliere i primi feedback prima di lanciare le regioni europee e nordamericane.

Le prime ondate di patch + reboot vengono applicate agli host VPS in Australia. La regione SYD2 è terminata all'inizio del pomeriggio (ora di Parigi), senza incidenti. Le procedure vengono adeguate in base al feedback sul campo.

Non appena la procedura si è stabilizzata, inizia il follow the sun: ogni regione prende il relais a turno, nella sua mattinata locale, trasmettendo il contesto alla successiva. La prima ondata europea (RBX, GRA6, WAW, DE, SBG, MIL, UK) viene lanciata la sera stessa, alle 18:30 ora di Parigi.

Due perimetri, due esposizioni: VPS prima, Public Cloud dopo

La diffusione non è uniforme. VPS e Public Cloud si differenziano per l'architettura e l'esposizione al cliente. Il numero di macchine virtuali su host VPS è più elevato e molte aziende e privati utilizzano VPS per infrastrutture di test; la probabilità di un test client del codice di esecuzione sulla propria macchina virtuale è molto elevata e l'impatto è altrettanto elevato a causa del numero di macchine virtuali su ogni host.

Sul VPS, il perimetro per host è contenuto e l'impatto sul cliente per riavvio resta sotto controllo. I lotti possono essere concatenati rapidamente, consentendo di proteggere una grande parte del parco già nelle prime 24 ore.

Il cloud pubblico presenta un'esposizione di altro genere. Una regione concentra migliaia di clienti e un host può ospitare istanze critiche. Le regioni più grandi contengono centinaia o persino migliaia di host con complesse infrastrutture client virtuali. Decidiamo di dare priorità:

• per dimensione della regione: le regioni con una densità più bassa vengono elaborate per prime, al fine di convalidare la robustezza della procedura su larga scala;
• per numero di clienti esposti: le regioni ad alto volume vengono orchestrate con una granularità più fine, lotto per lotto, per diluire il rischio.

Stop-time e controllo del tempo

Ogni ondata di riavvii è soggetta a una soglia di arresto : se il numero di host in panne simultanea supera una soglia predefinita, l'ondata viene sospesa. Questa soglia è fissata a 15 host per le regioni ad alta densità (GRA, RBX, BHS) e a 5 host per le altre. La chiusura è inoltre attivata alle 06:00 o su richiesta del data center locale.

Questo dispositivo consente di non peggiorare una situazione di guasto hardware continuando a riavviare host che i tecnici DC non sono ancora riusciti a gestire. Introduce un punto di regolazione tra l'automazione software e la realtà fisica sul campo.

Non riavviare contemporaneamente due istanze di uno stesso progetto: l'anti-affinità come scudo di sicurezza

Il rischio principale per i nostri clienti in una tale operazione non è il reboot stesso, ma la interruzione simultanea di più istanze di uno stesso progetto, garantendo una resilienza applicativa in grado di far fronte a un guasto del provider. Un cliente che ha distribuito i carichi di lavoro su più host per garantire l'alta disponibilità non deve vedere tutte le istanze passare simultaneamente. La decisione è stata presa di andare oltre il rispetto delle regole anti-affinità che potrebbero essere state definite nei roll-out dei clienti.

Pertanto, per ogni progetto client con istanze distribuite su più host, i nostri orchestratori calcolano un grafo di co-localizzazione. In nessun momento due host che portano istanze dello stesso progetto vengono riavviati nella stessa finestra: vengono definite onde mutuamente esclusive e un host deve essere di nuovo in servizio prima di lanciare il successivo nella stessa classe di anti-affinità.

Questa anti-affinità viene applicata con best effort : è rispettata nella maggior parte dei casi, ma non può essere garantita al 100 % sull'intero parco. L'obiettivo rimane quello di sequenziare l'impatto in modo che sia assorbibile dal lato applicativo. I clienti le cui istanze dipendono da un solo host subiscono un'interruzione puntuale, la cui finestra è annunciata.

Live-migration prioritaria per i servizi e i carichi di lavoro sensibili

Dietro ogni istanza client ci sono controller, API, schemi di dati, database interni. Un reboot incontrollato dei host che ospitano questi servizi creerebbe deadlock : un servizio interno non disponibile blocca la successione dei reboot, che a sua volta blocca il patching. Inoltre, alcuni servizi OVHcloud si basano su macchine virtuali ospitate nelle istanze Public Cloud. La considerazione di questi casi è indispensabile per limitare gli impatti sui clienti.

Per evitare questa cascata, la priorità viene invertita: viene effettuata un'analisi approfondita delle dipendenze dei servizi interni a monte di ogni riavvio della regione. Alcuni servizi interni sono live-migrati. Le loro macchine virtuali vengono spostate in modalità "hot" su host già patchati, la catena di dipendenze viene mantenuta disponibile e l'host viene rilasciato per il reboot.

Questa procedura è lunga e consuma intensamente risorse materiali e umane. Essa deve essere limitata a un numero ridotto di macchine virtuali per rispettare l’obiettivo di contenere nel tempo la migrazione.

Alcuni carichi di lavoro richiedono un'attenzione particolare: in particolare, i servizi Cloud Databases (DBaaS), il Datalake interno e le funzioni di Observability vengono migrati una VM alla volta, senza spegnere più di una macchina contemporaneamente, differendo l'aggiornamento dei loro host il più a lungo possibile. Questa transizione agevole evita interruzioni a cascata dei servizi e garantisce la continuità operativa degli strumenti di supporto.

Incidenti tecnici e modifiche in corso

Un intervento di questa portata non si svolge senza intoppi. Nel corso della campagna sono stati riscontrati e risolti diversi problemi tecnici.

Le VM non si riavviano dopo il reboot dell'host

Il primo incidente di rilievo è apparso fin dalla prima ondata europea: le macchine virtuali non si riavviavano dopo il reboot del loro hypervisor. Nova compute segnalava "Instance shutdown by itself" senza sincronizzazione. La causa radice viene identificata il secondo giorno: il servizio libvirt-guests entrava in conflitto con nova compute e interrompeva le istanze al riavvio senza sincronizzazione lato API. Il workaround applicato consiste nel disattivare e nascondere libvirt-guests.service sugli host prima del reboot. Con questo fix, i riavvii automatici delle VM funzionano.

Corruzione dei dati sui servizi sincroni

La sera del secondo giorno, il sistema di monitoraggio interno segnala dati corrotti su più VMs distribuiti su 3 cluster. La causa probabile: il reboot forzato avveniva nel bel mezzo della scrittura su disco. Il graceful shutdown viene quindi esteso a 60 secondi prima dell'interruzione forzata, per lasciare il tempo alle scritture di terminare. È stato implementato uno script di riavvio automatico delle VM rimaste spente.

Deadlock API a Parigi

Nella notte tra il secondo e il terzo giorno, le API Nova e Neutron a Parigi entrano in deadlock reciproco : l’API Neutron (limitata a 10 processi) si satura sotto un’ondata di richieste da Nova, restituendo HTTP 503 per circa due ore. Il fix consiste nell'aumentare i workers Neutron da 10 a 30 e i process Apache da 10 a 32. Le zone B di Parigi e Milano sono state posticipate per consentire la stabilizzazione.

Saturazione supporto a BHS

Sul sito di BHS (Canada), il traffico API raggiunge 10 volte il traffico massimo abituale, saturando il Manager e il supporto. Alcuni clienti hanno scoperto l’impatto prima di ricevere la comunicazione. Questo caso illustra concretamente le reazioni a catena all’interno dell’infrastruttura.

Questi bug e problemi riscontrati sono stati tutti gestiti nell'ambito delle operazioni, ma saranno presi in considerazione per implementare i miglioramenti adeguati in modo duraturo.

I reboot e gli interventi hardware

Un reboot di decine di migliaia di macchine implica anche una dimensione materiale. C'è un tasso di guasto intrinseco a qualsiasi reboot del server. La prima notte, circa 20-30 host su 6.000 non sono tornati da soli: schede di memoria difettose, configurazione del BIOS, interfaccia di rete inattiva. Negli Stati Uniti, diversi host hanno richiesto una rimozione della batteria CMOS e uno scarico di alimentazione prima del riavvio — un profilo hardware ricorrente.

Ogni sede ha tecnici del centro dati mobilitati a supporto durante la campagna. Il loro ruolo:

• intervenire in emergenza sugli host in crash di reboot segnalati dagli orchestrator;
• sostituire le parti difettose (dischi, memorie, alimentatori);
• effettuare i gesti di prossimità che nessun tool può automatizzare: hard reboot fisico, verifica dei led, intervento in baia.

I tecnici del data center operano in modalità intervento prioritario sugli host in errore, in coordinamento con i team Run/SRE che danno priorità in base all'esposizione del cliente all'host. Un host che porta istanze critiche e non ritorna passa davanti a un host libero. Questa priorità incrociata – logica e fisica – è ciò che mantiene il tempo dell’operazione.

Comunicazione e supporto: informare i clienti interessati

Un patching unilaterale a impatto controllato non può essere concepito senza uno sforzo di comunicazione proporzionato.

Una comunicazione mirata e progressiva

Di fronte alla dinamica del follow the sun, una comunicazione globale e indifferenziata non avrebbe avuto alcun senso. La strategia adottata è stata una comunicazione mirata e graduale : indirizzata solo ai clienti le cui istanze sono ospitate su host programmati per il reboot, e attivata man mano che l'operazione progrediva, regione per regione, ondata per ondata.

Inizialmente, si decide di non attivare una pagina di stato pubblica, per non esporre la sequenza di distribuzione. Le comunicazioni avvengono attraverso targeted communications tramite il nostro portale Supporto, con l'invio di email ai clienti con un livello di Supporto Business ed Enterprise.

Rilevamento: alcuni messaggi non vengono recapitati

Gli strumenti di comunicazione hanno dei limiti tecnici. Per le regioni con un elevato volume come GRA6 (quasi 90.000 clienti non contattati), l'invio di massa di e-mail è evitato per evitare la moltiplicazione di ticket di supporto.

Di fronte a questa constatazione, viene deciso un punto di svolta nel secondo giorno: implementare un banner condizionale nel Manager tramite un feature flipping — se l'utente connesso è presente nella lista dei conti client (NIC) interessati, viene visualizzato un messaggio di informazione. Lo sviluppo viene eseguito durante il giorno e il banner viene distribuito il terzo giorno. In questo momento viene creata anche una pagina di stato per Public Cloud.

Nonostante questi dispositivi, alcuni messaggi non sono arrivati ai loro destinatari: indirizzi di contatto obsoleti, notifiche filtrate, disallineamento tra l'ora prevista del reboot e l'ora di invio. Alcuni clienti hanno scoperto l’impatto senza essere stati avvertiti in anticipo. Questi punti di rottura sono identificati come assi di miglioramento prioritari al termine del piano di mitigazione iniziale.

Il supporto come canale di ultima istanza

Per i clienti non informati, o che richiedono chiarimenti, il supporto clienti è stato rafforzato e preparato: briefing preliminare sul contesto dell'operazione, accesso in tempo reale allo stato di avanzamento per regione e per host, trattamento accelerato dei ticket legati alla campagna attraverso un circuito dedicato.

Il supporto recupera ciò che le notifiche automatiche non sono riuscite a portare. Non sostituisce la comunicazione, ma ne compensa alcuni dei difetti.

Cronologia dell'operazione

Prospettive

La vulnerabilità CVE-2026-53359 metteva a rischio i nostri clienti e le nostre infrastrutture. Il piano d'azione di mitigazione ha avuto un impatto cliente: contenuto, sequenziato, annunciato, ma reale. Comunicare in modo più dettagliato durante l'esecuzione del piano d'azione, finché l'infrastruttura non fosse stata corretta, avrebbe aumentato significativamente il rischio per i nostri clienti, spingendo alcuni di loro a "testare" l'exploit disponibile pubblicamente.

Riavviare un parco di dimensioni globali con un impatto zero non era un obiettivo raggiungibile. L'obiettivo era quindi la minor entità di impatto compatibile con la sicurezza dell'intero parco.

Patcher e riavviare tutti gli host Public Cloud e VPS non era mai stato fatto con questo vincolo di tempo. Questa procedura di emergenza è stata messa a punto in considerazione del rischio legato alla vulnerabilità. I casi precedenti sono sempre stati gestiti con un reboot progressivo utilizzando il tasso di rotazione naturale delle macchine virtuali sull'infrastruttura, combinato con live-migrate ad-hoc pianificate su un tempo lungo.

I team coinvolti in questa operazione hanno realizzato un exploit con un numero di guasti e impatto cliente molto ragionevole rispetto alle dimensioni del cantiere. Tuttavia, consapevoli che i prossimi mesi potrebbero dare luogo ad altre pubblicazioni di vulnerabilità del kernel, sembra ormai consolidato che questa procedura di emergenza dovrà essere ripetuta. Dovremo fare meglio la prossima volta, sia nel controllo dell'impatto lordo dei riavvii che nell'informazione a monte dei clienti e nella procedura di accompagnamento dei clienti interessati durante le operazioni. Quindi, nei prossimi giorni e settimane, identificheremo i principali impatti presso i nostri clienti che hanno subito interruzioni complesse e lavoreremo internamente ai problemi riscontrati durante le operazioni, in post mortem, al fine di migliorare le nostre procedure in futuro.