Resoconto di un intervento correttivo eseguito in una settimana su tutto il nostro parco KVM, seguendo una strategia di patching il cui obiettivo centrale era minimizzare l'impatto sui servizi dei nostri clienti.

Una vulnerabilità nel sottosistema di virtualizzazione

Martedì 7 luglio, nel primo pomeriggio, è scattato un allarme di sicurezza relativo alla 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, presente da diversi anni, è stata resa pubblica il 6 luglio e nei blog di altri provider cloud appare già il 7.

KVM è il motore di virtualizzazione su cui si basa la stragrande maggioranza delle istanze ospitate da OVHcloud. Il meccanismo è il seguente: in caso di modifica esterna di una Page Directory Entry (PDE), la voce RMAP può conservare un riferimento a una pagina di memoria già liberata. Il kernel dereferenzia quindi la pagina obsoleta, con possibili conseguenze quali il crash dell'hypervisor o, negli scenari peggiori, un’escalation dei privilegi a livello dell’host. L'exploit è riproducibile: un test interno su un host senza patch causa un crash in circa due minuti.

I sistemi interessati sono tutti i kernel Linux x86 precedenti al commit della patch, indipendentemente dalla distribuzione. La patch ufficiale è stata applicata ai nostri kernel di produzione Debian.

I rischi da considerare sono principalmente 3:

• l’utilizzo dell'exploit da parte di un cliente VPS per causare il crash dell'host che fa funzionare la propria macchina virtuale, provocando il crash e il reboot non controllato di diverse centinaia di macchine virtuali di altri clienti.
• lo stesso scenario sulle istanze Public Cloud genera un 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, gestori di code, load balancer, etc.). Questi sistemi sono spesso utilizzati in architetture applicative composite con dipendenze complesse.
• la probabilità della futura pubblicazione di un exploit che permetta di prendere il controllo dell'host, aumentando immediatamente la soglia 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 questione quindi non è stabilire se è necessario applicare una patch, ma come realizzare questa operazione su una scala così ampia tenendo conto che l’impatto per i clienti non può essere nullo.

Le possibili opzioni per mitigare il rischio

1: attendere i kernel ufficiali con la patch applicata

Questa opzione ci renderebbe dipendenti dalle tempistiche di una terza parte, lasciandoci esposti al rischio per un periodo non prevedibile. In considerazione del rischio, l'abbiamo scartata rapidamente.

2: live patch

L’applicazione di una live patch richiede di autorizzare questo tipo di operazione nella configurazione del kernel, consentendo la modifica dinamica del suo comportamento. Questo implica anche una riduzione del livello di hardening, limitando le capacità di rilevamento in caso di compromissione del kernel stesso. La live patch è inoltre una procedura sensibile per natura, che può portare a uno stato di instabilità a livello del parco. Questa opzione consentirebbe di risparmiare tempo in attesa di una soluzione permanente ma abbiamo deciso di non accettare questo compromesso, in quanto avrebbe aumentato significativamente il rischio in caso di pubblicazione di un exploit in grado di prendere il controllo dell'host.

3: mitigazione tramite disattivazione della virtualizzazione nidificata

Disattivare la virtualizzazione nidificata sugli host permette di rendere l'exploit inefficace. Non avremmo però visibilità sull'utilizzo di questa funzionalità da parte dei nostri clienti e non sarebbe quindi possibile determinarne l'impatto sui loro servizi. Questa funzionalità è inoltre necessaria per conservare la capacità di migrazione in tempo reale da un'istanza di un host fisico a un altro. Abbiamo rapidamente scartato questa pista.

4: live migration

Organizzare la migrazione live delle macchine virtuali dagli host vulnerabili verso host vuoti aggiornati nel frattempo è una soluzione interessante in termini di continuità del servizio, poiché la migrazione avviene senza impatto sulle macchine virtuali, fatta eccezione per un calo delle prestazioni durante l’operazione. Questa opzione richiede però molto tempo per copiare le macchine virtuali da host a host; non è quindi realisticamente utilizzabile su ampia scala e non ci permetterebbe di proteggere i nostri clienti in pochi giorni anziché in diversi mesi. Abbiamo deciso di considerare questa opzione solo per alcune macchine virtuali critiche, perché ogni migrazione live provoca un ritardo elevato nell'esecuzione dei batch.

5: backport della patch sui nostri kernel e reboot di tutti gli host

La scelta finale è ricaduta su questa opzione, che descriveremo in dettaglio nel seguito dell'articolo.

Martedì pomeriggio: attivazione e organizzazione dell’unità di crisi

Dalla conferma della vulnerabilità, la priorità è costruire una risposta strutturata e coordinata; gli analisti incaricati di questa prima analisi comprendono molto rapidamente le criticità dei giorni successivi. L’informazione si diffonde internamente nel primo pomeriggio e vengono aperti diversi spazi di coordinamento: uno per il coordinamento tecnico, uno per il coordinamento della crisi, uno per le operazioni negli Stati Uniti, uno per la comunicazione con i clienti e il supporto. Nel frattempo i team Kernel preparano ed effettuano il backport della patch: il primo kernel corretto è consegnato la sera stessa e subito vengono eseguiti i test di validazione in un ambiente dedicato. La patch viene confermata: l'exploit non provoca più il crash degli hypervisor corretti e i test di QA con il kernel danno risultati positivi.

L’unità di crisi si evolve verso un monitoraggio del deploy e passa sotto la gestione del NOC (Network Operations Center), che assume il ruolo di coordinatore operativo: controllo degli avanzamenti globali, definizione delle priorità tra Region e servizi, mantenimento di una visione complessiva. L'esecuzione è affidata agli esperti Public Cloud e VPS, che eseguono i reboot, le migrazioni live 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.

Inoltre, dato che l'operazione segue il principio “follow the sun”, l’unità funziona 24/7 con una rotazione per area geografica. Ogni giorno vengono effettuati tre riunioni di allineamento, in corrispondenza delle transizioni di zona. Durante questi incontri NOC, esperti operativi e team di supporto e sicurezza condividono lo stato di avanzamento nelle diverse Region, effettuano il passaggio di consegne tra le diverse zone (ciò che ha funzionato, adeguamenti procedurali basati sull’esperienza sul campo) e definiscono le priorità della fase successiva.

L’unità completa riunisce, tramite rotazione 24/7, i team Kernel & Virtualization (analisi della patch, backport, validazione), VPS e Public Cloud (implementazione), NOC (gestione), Run & SRE (orchestrazione, anti-affinità, live migration), Datacenter Operations (interventi hardware), Supporto Clienti (richieste dei clienti), Sicurezza (controllo, perimetro, fine dell'operazione) e Comunicazione (trasparenza, notifiche mirate).

L'obiettivo assegnato è chiaro: applicare la patch e riavviare gli host interessati il più rapidamente possibile, per ridurre la finestra di vulnerabilità e minimizzare l'impatto sui servizi. Il principale vincolo è rappresentato dall’entità dell’operazione: decine di migliaia di macchine su cui intervenire in tutti i continenti, sapendo che una gestione caso per caso è materialmente impossibile con questi volumi.

Il rischio maggiore in questa fase è lo sfruttamento della vulnerabilità con il conseguente crash degli host senza patch. L’unità di crisi decide di applicare la correzione a livello globale prima della fase di riavvio. In questo modo, in caso di sfruttamento della vulnerabilità, il crash di un host comporterà il suo riavvio e l'applicazione automatica della patch. Esiste anche 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 qualcuno riesca a utilizzare la vulnerabilità per prendere il controllo di un host. In uno scenario di tale gravità, sappiamo che ogni minuto è prezioso.

Una decisione consapevole: patching unilaterale a impatto controllato

Il Comitato Esecutivo approva il Go/No Go in serata: l’intervento verrà eseguito nella prima Region la mattina successiva. Per un numero così elevato di macchine, non esiste uno scenario senza impatto. Negoziare una finestra di manutenzione con ciascun cliente, verificare ogni dipendenza, pianificare su misura ogni riavvio sono tutti step materialmente incompatibili con una tempistica accettabile rispetto al rischio di sicurezza.

L’unità di crisi prende quindi una decisione consapevole: un patching unilaterale a impatto controllato, applicato senza attendere l'accordo individuale con ogni cliente e con la consapevolezza che alcuni servizi subiranno un'interruzione. La motivazione si basa su tre punti:

• non applicare la patch espone l'intero parco a una vulnerabilità con rischio elevato;
• una gestione caso per caso allungherebbe le tempistiche e lascerebbe la maggior parte degli host vulnerabili per settimane;
• un'azione rapida e globale consente di proteggere il maggior numero di utenti, accettando un impatto temporaneo su una minoranza di essi.

La priorità non è più quindi evitare l'impatto, ma minimizzarlo, distribuirlo e renderlo prevedibile. Questa logica struttura l'intera operazione: approccio follow the sun, prioritizzazione delle Region e pianificazione anti-affinità.

Mercoledì 8 luglio: avvio delle attività da Sydney

La scelta di Sydney per testare il deploy è scontata: il numero di host è limitato e l’intervallo di deployment in orario non lavorativo locale (durante la notte) corrisponde agli orari d’ufficio dei team in Europa. Iniziare dalla Region più a est consente di:

• intervenire nella zona con il minor carico operativo;
• validare la procedura in condizioni reali e su scala ridotta prima dell’industrializzazione;
• raccogliere i primi feedback prima di procedere con le Region europee e nordamericane.

Le prime attività di patch e reboot vengono applicate agli host VPS in Australia. La Region SYD2 è completata nel primo pomeriggio (ora di Parigi), senza incidenti. Le procedure vengono adeguate sulla base dei riscontri raccolti sul campo.

Una volta stabilizzata la procedura, il follow the sun ha inizio: ogni Region subentra a turno durante il proprio orario mattutino locale, trasmettendo il contesto alla successiva. La prima ondata europea (RBX, GRA6, WAW, DE, SBG, MIL, UK) viene avviata la sera stessa, alle 18:30 ora di Parigi.

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

Il deploy non è uniforme. VPS e Public Cloud differiscono per architettura ed esposizione al cliente. Il numero di macchine virtuali su host VPS è maggiore e molte aziende e privati utilizzano i VPS per ambienti di test. La probabilità che un cliente provi il codice di exploit sulla propria macchina virtuale è quindi molto elevata, così come l'impatto, a causa della quantità di macchine virtuali su ogni host.

Sui VPS, il perimetro per host è contenuto e l'impatto sui clienti in seguito a un reboot rimane sotto controllo. I lotti possono essere concatenati rapidamente, consentendo di proteggere una grande parte del parco già nelle prime 24 ore.

Il Public Cloud presenta invece un'esposizione di altro genere. Una Region concentra migliaia di clienti e un host può ospitare istanze critiche. Le regioni più grandi contano centinaia o persino migliaia di host con infrastrutture virtuali complesse. Decidiamo di stabilire una priorità basata su:

• dimensione della Region: le Region con densità minore vengono trattate per prime, in modo da verificare la solidità della procedura su larga scala;
• numero di clienti esposti: le Region con volume elevato vengono orchestrate con una granularità più fina, lotto per lotto per limitare il rischio.

Soglie di arresto e controllo della velocità di esecuzione

Ogni ondata di reboot è soggetta a una soglia di arresto: se il numero di host simultaneamente non funzionanti supera il limite definito, l'ondata viene sospesa. Questa soglia è fissata a 15 host per le Region a densità elevata (GRA, RBX, BHS) e a 5 host per le altre. Un arresto viene inoltre attivato alle 06:00 oppure su richiesta del datacenter locale.

Questo meccanismo consente di non aggravare una situazione di guasto hardware continuando a riavviare host se i tecnici del datacenter non sono ancora riusciti a intervenire. Stabilisce 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 misura di protezione

Il principale rischio per i nostri clienti in un’operazione di questo tipo non è il reboot in sé, ma l’interruzione simultanea di più istanze di uno stesso progetto che garantiscono una resilienza applicativa in grado di far fronte a eventuali problemi del fornitore. Un cliente che ha distribuito i carichi di lavoro su più host per assicurare l’alta disponibilità non dovrebbe vedere tutte le sue istanze spegnersi contemporaneamente. È stato deciso di andare oltre il semplice rispetto delle regole di anti-affinità eventualmente definite nei deploy dei clienti.

Pertanto, per ogni progetto cliente con istanze distribuite su più host, i nostri orchestratori calcolano un grafo di co-localizzazione. Due host che ospitano istanze dello stesso progetto non vengono mai riavviati nella stessa finestra temporale, ma vengono definite ondate mutualmente esclusive in modo che un host debba essere nuovamente operativo prima di avviare l’operazione successiva nella stessa classe di anti-affinità.

Questa anti-affinità viene applicata in best effort: è rispettata nella maggior parte dei casi, ma non può essere garantita al 100% sull'intero parco. L'obiettivo resta quello di sequenziare l'impatto per renderlo minore a livello applicativo. I clienti le cui istanze si trovano su un solo host subiscono un'interruzione puntuale in una finestra temporale annunciata.

Live migration prioritaria di servizi e carichi di lavoro sensibili

Dietro ogni istanza del cliente si trovano controller, API, data plane e database interni. Un riavvio inaspettato degli host che ospitano questi servizi potrebbe creare un 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 su istanze Public Cloud. Considerare queste casistiche è indispensabile per limitare gli impatti sui clienti.

Per evitare questo effetto domino, l’ordine delle priorità è invertita e l'analisi dettagliata delle dipendenze dei servizi interni viene effettuata prima di ogni riavvio della Region. Alcuni servizi interni sono migrati in tempo reale. Le loro macchine virtuali vengono spostate a caldo verso host già corretti da patch, la catena di dipendenze viene mantenuta disponibile e l'host viene liberato per il reboot.

Questa procedura è lunga e caratterizzata da un consumo intensivo di risorse hardware e umane. Deve quindi essere limitata a un numero ridotto di macchine virtuali per rispettare l’obiettivo di contenere nel tempo la migrazione.

Alcuni carichi di lavoro richiedono particolare attenzione, nello specifico i servizi Cloud Databases (DBaaS), il Datalake interno e le funzionalità di Observability vengono migrati una VM alla volta, senza spegnere più macchine contemporaneamente, posticipando l'aggiornamento dei loro host il più a lungo possibile. Questa transizione graduale evita interruzioni a cascata dei servizi e assicura la continuità operativa degli strumenti di supporto.

Incidenti tecnici e adattamenti in corso d’opera

Un’operazione di questa portata non può svolgersi senza inconvenienti. Durante la campagna sono emersi diversi problemi tecnici, successivamente risolti.

VM che non si riavviano dopo il reboot dell'host

Il primo incidente maggiore è avvenuto sin 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. L’origine del problema viene identificata il secondo giorno: il servizio libvirt-guests entrava in conflitto con Nova Compute, interrompendo le istanze al riavvio senza sincronizzazione lato API. La correzione applicata consiste nel disattivare e mascherare libvirt-guests.service sugli host prima del reboot. Con questa modifica, il riavvio automatico delle VM riprende a funzionare normalmente.

Corruzione dei dati sui servizi sincroni

La sera del secondo giorno il sistema di monitoraggio interno segnala la presenza di dati corrotti su diverse VM distribuite in 3 cluster, probabilmente causato dall’esecuzione del reboot forzato nel bel mezzo della scrittura su disco. Il graceful shutdown viene quindi esteso a 60 secondi prima dell'interruzione forzata, per lasciare il tempo sufficiente a completare le scritture. Viene inoltre 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 per un’ondata di richieste provenienti da Nova, restituendo errori HTTP 503 per circa due ore. La soluzione consiste nell'aumentare i worker Neutron da 10 a 30 e i process Apache da 10 a 32. Le zone B di Parigi e Milano vengono posticipate per il tempo necessario a stabilizzare il sistema.

Saturazione del supporto a BHS

Sul sito di BHS (Canada) il traffico API raggiunge un volume 10 volte superiore a quello abituale, saturando Spazio Cliente e supporto. Alcuni clienti sono venuti a conoscenza dell’impatto prima di riceverne comunicazione. Questo caso evidenzia in modo concreto le reazioni a catena all’interno dell’infrastruttura.

Tutti i bug e i problemi rilevati sono stati gestiti durante le attività, ma verranno successivamente utilizzati per implementare miglioramenti efficaci e duraturi.

Reboot e interventi hardware

Il riavvio di decine di migliaia di macchine implica anche una dimensione hardware. Qualsiasi operazione di reboot presenta infatti un rischio intrinseco di malfunzionamento. La prima notte circa 20-30 host su 6.000 non sono tornati operativi autonomamente: schede di memoria difettose, configurazione BIOS, interfaccia di rete inattiva. Negli Stati Uniti diversi host hanno richiesto una rimozione della batteria CMOS e un’interruzione dell’alimentazione prima del riavvio, una procedura hardware diffusa.

Durante la campagna su ogni sito sono stati mobilitati tecnici di datacenter per fornire supporto, con il ruolo di:

• intervenire tempestivamente sugli host in errore in fase di reboot segnalati dagli orchestrator;
• sostituire i componenti difettosi (dischi, schede di memoria, alimentatori);
• effettuare le azioni di prossimità che nessuno strumento può automatizzare, come hard reboot fisico, verifica delle spie luminose, interventi sui rack.

I tecnici dei datacenter lavorano in modalità di intervento prioritario sugli host in errore, in coordinamento con i team Run/SRE che definiscono le priorità in base all'esposizione dell'host del cliente. Un host che ospita istanze critiche e non torna operativo passa davanti a un host vuoto. Questa priorità incrociata, software e fisica, è ciò che permette il corretto avanzamento dell’attività.

Comunicazione e supporto: informare i clienti coinvolti

Un patching unilaterale a impatto controllato deve essere necessariamente accompagnato da uno sforzo di comunicazione adeguato.

Comunicazione mirata e progressiva

Con la dinamica “follow the sun”, una comunicazione globale e non differenziata sarebbe risultata inefficace. È stata quindi adottata una strategia di comunicazione mirata e graduale, rivolgendosi esclusivamente ai clienti con istanze ospitate su host programmati per il reboot e procedendo in base all’avanzamento dell’intervento, Region dopo Region e ondata dopo ondata.

Inizialmente viene deciso di non attivare una pagina di stato pubblica, per non mostrare la sequenza di deploy. Le comunicazioni vengono gestite con messaggi mirati tramite il nostro portale di supporto, inviando email ai clienti con un livello di supporto Business o Enterprise attivo.

Constatazione: alcuni messaggi non vengono recapitati

Gli strumenti di comunicazione presentano limiti tecnici. Per le Region con un volume elevato come GRA6 (quasi 90.000 clienti non contattati), l'invio massivo di email viene escluso per evitare un incremento dei ticket di supporto.

A seguito di questa constatazione, il secondo giorno viene adottata una nuova strategia, che prevede l’implementazione di un banner condizionale nello Spazio Cliente tramite feature flipping: se l'utente connesso è presente nella lista degli account cliente (NIC) interessati, viene mostrato un messaggio informativo. Il banner viene sviluppato nell’arco della giornata e pubblicato il terzo giorno. Parallelamente viene creata anche una pagina di stato per il Public Cloud.

Nonostante queste misure, alcuni messaggi non sono arrivati ai destinatari a causa di indirizzi di contatto obsoleti, notifiche filtrate, disallineamento tra l'orario previsto per il riavvio e l'ora di invio. Alcuni clienti hanno scoperto l’impatto senza esserne stati preventivamente informati. Questi punti di rottura sono stati identificati come aree di miglioramento prioritarie al termine del piano di mitigazione iniziale.

Il supporto come canale di ultima istanza

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

Il supporto prende in carico ciò che le notifiche automatiche non sono riuscite a trasmettere. Non sostituisce la comunicazione, ma ne compensa alcune lacune.

Sequenza temporale dell'operazione

Prospettive

La CVE-2026-53359 esponeva i nostri clienti e le nostre infrastrutture a un rischio. Il piano d'azione di mitigazione ha avuto un impatto sui clienti: contenuto, sequenziato, annunciato, ma reale. Fornire maggiori dettagli durante l'attuazione del piano d'azione, prima del completamento del patching dell'infrastruttura, avrebbe aumentato significativamente il rischio per i clienti spingendo alcuni di loro a "testare" l'exploit disponibile pubblicamente.

Il riavvio di un parco su scala mondiale senza nessuna conseguenza non era un risultato raggiungibile. L'obiettivo era quindi ridurre l’impatto al minimo possibile mantenendo la sicurezza dell'intera infrastruttura.

Applicare una patch e riavviare tutti gli host Public Cloud e VPS non era mai stato realizzato in tempi così ridotti. Questa procedura di emergenza è stata adottata in considerazione del rischio legato alla vulnerabilità. Le situazioni precedenti erano sempre state gestite con reboot progressivi, basati sul normale ciclo di rotazione delle macchine virtuali sull'infrastruttura e combinato con attività di live migration pianificate ad-hoc su un arco temporale esteso.

I team coinvolti in questa operazione hanno realizzato una vera e propria impresa, con un numero di guasti e di impatti sui cliente ragionevole rispetto alle proporzioni dell’intervento. Siamo però consapevoli che nei prossimi mesi potrebbero essere pubblicate nuove vulnerabilità del kernel e in questo caso è probabile che questa procedura di emergenza debba essere ripetuta. La prossima volta dovremo essere ancora più efficaci nella gestione dell'impatto finale dei riavvii, nella comunicazione preventiva ai clienti e nell’assistenza dei clienti interessati durante le operazioni. Nei prossimi giorni e settimane identificheremo quindi i principali impatti per i clienti che hanno subito interruzioni complesse e lavoreremo internamente sui problemi emersi durante le operazioni, in post mortem, per migliorare le nostre procedure in futuro.