Ervaringen met een correctieoperatie die in één week tijd op ons gehele KVM-park is uitgevoerd, volgens een patchstrategie waarvan het centrale doel was om de impact op de diensten van onze klanten te minimaliseren.

Een kwetsbaarheid in het virtualisatiesubsysteem

Op dinsdag 7 juli, begin van de middag, kwam er een beveiligingswaarschuwing binnen over CVE-2026-53359, een kwetsbaarheid van het type use-after-free die het shadow-paging-subsysteem van KVM x86 in de Linux-kernel treft. Het lek, dat al enkele jaren oud is, werd op 6 juli openbaar gemaakt; blogs van andere cloudproviders verschenen al op de 7e.

KVM vormt de virtualisatie-engine waarop het overgrote deel van de bij OVHcloud gehoste instanties draait. Het mechanisme is als volgt: wanneer een externe wijziging van een Page Directory Entry (PDE) optreedt, kan het RMAP-item een verwijzing behouden naar een reeds vrijgegeven geheugenpagina. De kernel derefereert vervolgens deze verouderde pagina, wat kan leiden tot een crash van de hypervisor of, in de slechtste scenario's, tot privilege-escalatie aan de hostzijde. De exploit is reproduceerbaar: een interne test op een niet-gepatchte host veroorzaakt binnen ongeveer twee minuten een crash.

Alle Linux x86-kernels van vóór de commit met de correctie zijn getroffen, ongeacht de distributie. De officiële patch is ge-backport naar onze Debian-productiekernels.

Er zijn 3 hoofdzakelijke risico's om rekening mee te houden:

• Een VPS-klant gebruikt de exploit om de host te laten crashen waarop zijn virtuele machine draait: crash en ongecontroleerde herstart van honderden virtuele machines van klanten.
• Hetzelfde scenario bij Public Cloud-instanties; de impact is vergelijkbaar, maar het aantal virtuele machines per host is beperkter en de virtuele machines zijn krachtiger en worden gebruikt voor gevoeligere systemen (databases, queue-managers, load balancers, enz.). Deze systemen worden vaak gebruikt in samengestelde applicatiearchitecturen met complexe afhankelijkheden.
• Waarschijnlijkheid van de aanstaande publicatie van een exploit voor het overnemen van de host, wat het risiconiveau onmiddellijk onacceptabel zou verhogen vanwege de impact op de vertrouwelijkheid van klantgegevens en de integriteit van de infrastructuur.

Voor OVHcloud omvat het bereik tienduizenden hypervisor-hostservers, die ongeveer een miljoen virtuele machines hosten. De vraag is dus niet of er gepatcht moet worden, maar hoe deze operatie op een dergelijke schaal moet worden uitgevoerd, wetende dat een nul-impact voor de klant niet haalbaar is.

De opties die op tafel liggen om het risico te mitigeren

1.

Wachten op officiële gepatchte kernels

Deze optie maakte ons afhankelijk van een agenda van derden die ons in een risicostatus liet voor een onbeheerste periode. Wij hebben deze optie snel verworpen vanwege het risico.

2.

Live patch

Het toepassen van een live patch vereist dat dit type operatie wordt toegestaan in de kernelconfiguratie, wat het, per definitie, mogelijk maakt om het gedrag ervan on-the-fly te wijzigen, wat tegelijkertijd leidt tot een vermindering van het beveiligingsniveau en de detectiemogelijkheden beperkt in geval van een compromittering daarvan. Bovendien is de live patch van nature een gevoelige procedure die kan leiden tot een instabiele status op de schaal van het machinepark. Dit is een optie die tijd bespaart in afwachting van een duurzame oplossing. Wij hebben besloten dit compromis niet te sluiten, omdat dit het risico zeer sterk zou hebben verhoogd in het geval van de publicatie van een exploit voor het overnemen van de host.

3.

Mitigatie door uitschakeling van geneste virtualisatie

Het uitschakelen van geneste virtualisatie op de hosts maakt de exploit onwerkzaam. Wij hebben geen inzicht in het gebruik van deze functionaliteit door onze klanten, dus het is onmogelijk om de impact op klantendiensten te bepalen, en deze functionaliteit is noodzakelijk om de mogelijkheid tot Live migratie van een instantie van de ene fysieke host naar de andere te behouden. Wij sluiten deze optie snel uit.

4.

Live migratie

Een Live migratie van virtuele machines organiseren, van kwetsbare hosts naar lege hosts die in de tussentijd zijn gepatcht. Deze optie is zeer bevredigend wat betreft de continuïteit van de dienstverlening, omdat de migratie plaatsvindt zonder impact op de virtuele machines, met uitzondering van verminderde prestaties tijdens de migratie. Deze optie kost veel tijd vanwege het kopiëren van virtuele machines van host naar host; het is niet realistisch bruikbaar op de schaal van het machinepark en de wens om onze klanten binnen enkele dagen in plaats van enkele maanden te beschermen. Wij besluiten deze optie alleen voor bepaalde kritieke virtuele machines te behouden, aangezien elke Live migratie een aanzienlijke vertraging veroorzaakt in de uitvoering van de batches.

5. Backport van de patch naar onze kernels en reboot van alle hosts

Uiteindelijk is dit de optie die zal worden gekozen en die in het vervolg van het artikel zal worden toegelicht.Dinsdagmiddag: activering en organisatie van de crisiscelZodra de kwetsbaarheid is bevestigd, is de prioriteit om een gestructureerde en gecoördineerde respons op te bouwen; de analisten die verantwoordelijk zijn voor deze eerste analyse begrijpen zeer snel wat er de komende dagen op het spel staat. De informatie wordt begin van de middag intern verspreid. Er worden verschillende coördinatieruimtes geopend: één voor technische coördinatie, één voor crisiscoördinatie, één voor US-operaties, één voor klantcommunicatie en ondersteuning. Tegelijkertijd bereiden de Kernel-teams de patch voor en backporten deze; de eerste gepatchte kernel wordt 's avonds geleverd.De validatietests worden 's avonds in de testomgeving uitgevoerd. De patch is bevestigd, de exploit laat de gepatchte hypervisors niet langer crashen en de QA-tests slagen met de gepatchte kernel.De crisiscel evolueert naar een opvolging van de implementatie en wordt vervolgens

aangestuurd door het NOC (Network Operations Center), dat de rol van operationeel coördinator op zich neemt: opvolging van de algemene voortgang, arbitrage van prioriteiten tussen regio's en diensten, behoud van het totaaloverzicht. De uitvoering wordt gedragen door de experts Public Cloud en VPS, die de reboots, live-migraties en anti-affiniteitsbeperkingen uitvoeren. De scheiding tussen coördinatie en uitvoering is bewust: het NOC coördineert, de operationele teams handelen en rapporteren de technische statistieken en gebeurtenissen die nodig zijn voor de coördinatie.De synchronisatie met de

klantenservice (realtime voortgangsstatus om getroffen klanten te woord te staan) en de beveiligingsteams (monitoring van de kwetsbaarheid, validatie van de scope en de criteria voor het beëindigen van de operatie) wordt continu gewaarborgd.Aangezien de operatie volgens het 'follow the sun'-principe verloopt, werkt de cel

24/7 met een rotatie per geografische zone. Er worden elke dag drie synchronisatiemomenten gehouden, die de overgangen tussen de zones dekken. Deze brengen het NOC, de operationele experts, de klantenservice en de beveiliging samen om: de voortgang per regio te delen, het stokje over te dragen tussen zones (wat heeft gewerkt, procedurele aanpassingen op basis van feedback uit het veld), en prioriteiten voor de volgende reeks te bepalen.De volledige cel brengt, via een 24/7 rotatie, het volgende samen: de teams Kernel & Virtualization (analyse van de patch, backport, validatie), VPS en Public Cloud (implementatie), NOC (aansturing), Run & SRE (orkestratie, anti-affiniteit, live migratie), Datacenter Operations (hardware-interventies), klantenservice (klantverzoeken),

beveiliging (monitoring, scope, beëindiging van de operatie) en communicatie

(transparantie, gerichte meldingen).

Het gestelde doel is duidelijk:

de betreffende hosts zo snel mogelijk patchen en herstarten om het kwetsbaarheidsvenster te verkleinen, met minimale impact op de diensten. De belangrijkste beperking is de schaal: tienduizenden machines die moeten worden behandeld, verspreid over alle continenten, wetende dat een individuele aanpak bij dit volume materieel onmogelijk is.Het grootste risico in deze fase is het misbruik van de kwetsbaarheid, wat leidt tot een crash van de niet-gepatchte host. De crisiscel besluit om de patch globaal toe te passen voorafgaand aan de herstartfase. In het geval van een exploitatie van de kwetsbaarheid zal de crash van een host leiden tot een herstart en de automatische verwerking van de patch. Bovendien bestaat er een risico dat de CVE wordt misbruikt voor een kwaadwillige overname van de host. Er is geen exploitcode publiekelijk beschikbaar, maar we weten dat het slechts een kwestie van tijd is voordat een onderzoeker erin slaagt de kwetsbaarheid te gebruiken om de controle over de host over te nemen. Aangezien dit scenario catastrofaal is, weten we dat elke minuut telt.

Een weloverwogen besluit: eenzijdige patching met gecontroleerde impactHet Uitvoerend Comité valideert de Go/No-Go

• in de avond: de eerste regio wordt de volgende ochtend behandeld. Voor dit aantal machines bestaat er geen scenario zonder impact. Een onderhoudsvenster onderhandelen met elke klant, elke afhankelijkheid controleren, elke reboot op maat orkestreren — stuk voor stuk stappen die materieel onverenigbaar zijn met een acceptabele termijn in het licht van het beveiligingsrisico.
• Het crisisteam neemt daarom een weloverwogen besluit:
• eenzijdige patching met gecontroleerde impact

, toegepast zonder te wachten op de individuele toestemming van elke klant, in de wetenschap dat sommige diensten een onderbreking zullen ondervinden. De redenering berust op drie punten:niet patchen stelt het gehele machinepark bloot aan een kwetsbaarheid met een hoge ernstgraad;een behandeling per geval zou de doorlooptijden verlengen en de meerderheid van de hosts wekenlang kwetsbaar laten;

een snelle en alomvattende actie beschermt het grootste aantal, zelfs als dit een minderheid tijdelijk treft.

De prioriteit is dan niet langer om de impact te vermijden, maar om

• deze te minimaliseren, te verdunnen en voorspelbaar te maken
• . Deze lijn structureert de gehele operatie: follow the sun, prioritering van regio's en anti-affiniteitsplanning.
• Woensdag 8 juli: start vanuit Sydney

De keuze voor Sydney om de uitrol te testen is triviaal: het aantal hosts is beperkt en het uitrolvenster in lokale HNO (tijdens de nacht) komt overeen met de kantooruren van de teams in Europa. Beginnen bij de meest oostelijke regio maakt het mogelijk om:te werken in de minst belaste zone;de procedure onder reële omstandigheden te valideren, op kleine schaal, vóór industrialisatie;om de eerste feedback te verzamelen voordat de Europese en Noord-Amerikaanse regio's worden gelanceerd.De eerste golven van

patch + reboot worden toegepast op de VPS

-hosts in Australië. De regio SYD2 is begin van de middag (Parijse tijd) zonder incidenten afgerond. De procedures worden aangepast op basis van feedback uit het veld.

Zodra de procedure gestabiliseerd is, wordt het

follow the sun-principe toegepast: elke regio neemt het stokje over, tijdens de lokale ochtend, waarbij de context wordt doorgegeven aan de volgende. De eerste Europese golf (RBX, GRA6, WAW, DE, SBG, MIL, UK) wordt dezelfde avond gelanceerd, om 18:30 uur Parijse tijd.Twee perimeters, twee blootstellingen: Eerst VPS, daarna Public Cloud

De uitrol is niet uniform. VPS en Public Cloud verschillen zowel qua architectuur als qua klantblootstelling. Het aantal virtuele machines op VPS-hosts is groter en veel bedrijven en particulieren gebruiken VPS voor testinfrastructuren; de waarschijnlijkheid van een klanttest van de exploitatiecode op zijn virtuele machine is zeer hoog en de impact is dat ook vanwege het aantal virtuele machines op elke host.Op de VPS

• is de omvang per host beperkt en blijft de impact per reboot voor de klant beheersbaar. De batches kunnen snel achter elkaar worden uitgevoerd, waardoor een groot deel van het park al in de eerste 24 uur kan worden beveiligd.De
• Public Cloud kent een blootstelling van een andere orde. Een regio concentreert duizenden klanten en een host kan kritieke instanties hosten. De belangrijkste regio's tellen honderden tot zelfs duizenden hosts met complexe virtuele klantinfrastructuren. We besluiten prioriteiten te stellen:

op regio-omvang

: de regio's met een lagere dichtheid worden als eerste behandeld, om de robuustheid van de procedure op schaal te valideren;op aantal blootgestelde klanten: de regio's met een hoog volume worden met een fijnere granulariteit georkestreerd, batch voor batch, om het risico te spreiden.Stopdrempels en tempocontroleElke reboot-golf is onderworpen aan een stopdrempel: als het aantal gelijktijdig uitgevallen hosts een gedefinieerde drempel overschrijdt, wordt de golf opgeschort. Deze drempel is vastgesteld op

15 hosts

voor regio's met een hoge dichtheid (GRA, RBX, BHS) en op

5 hosts voor de overige. Een stop wordt ook geactiveerd om 06:00 uur of op verzoek van het lokale datacenter.Dit mechanisme maakt het mogelijk om een situatie van hardwarestoring niet te verergeren door door te gaan met het rebooten van hosts die de DC-technici nog niet hebben kunnen behandelen. Het introduceert een reguleringspunt tussen de softwarematige automatisering en de fysieke realiteit op het terrein.

Niet gelijktijdig twee instances van hetzelfde project rebooten: anti-affiniteit als vangnetHet grootste risico voor onze klanten tijdens een dergelijke operatie is niet de reboot zelf, maar de gelijktijdige onderbreking van meerdere instances van hetzelfde project die een applicatieve veerkracht garanderen die in staat is om een storing van de provider op te vangen. Een klant die zijn workloads over meerdere hosts heeft verdeeld om zijn hoge beschikbaarheid te garanderen, mag niet zien dat al zijn instances tegelijkertijd uitvallen. De beslissing is genomen om verder te gaan dan het naleven van de anti-affiniteitsregels die in klantimplementaties konden zijn gedefinieerd.Zo berekenen onze orchestrators voor elk klantproject met instances die over meerdere hosts zijn verdeeld, een

co-locatiegraaf. Op geen enkel moment worden twee hosts met instances van hetzelfde project in hetzelfde venster opnieuw opgestart: er worden wederzijds exclusieve golven

gedefinieerd en een host moet weer in bedrijf zijn voordat de volgende in dezelfde anti-affiniteitsklasse wordt gestart.

Deze anti-affiniteit wordt toegepast op best effort-basis: deze wordt in de meeste gevallen gerespecteerd, maar kan niet voor 100% op het gehele park worden gegarandeerd. Het doel blijft om de impact te sequencen zodat deze aan de applicatiezijde opvangbaar is. Klanten van wie alle instances op één enkele host rusten, ondergaan een incidentele onderbreking waarvan het venster wordt aangekondigd.

Prioritaire live-migratie van gevoelige services en workloadsAchter elke klant-instance bevinden zich controllers, API's, dataplannen en interne databases. Een ongecontroleerde reboot van de hosts die deze services dragen, zou deadlocks

creëren: een interne service die niet beschikbaar is, blokkeert het vervolg van de reboots, wat het patchen blokkeert. Bovendien rusten sommige OVHcloud-services op virtuele machines die worden gehost op de Public Cloud-instances. Het in aanmerking nemen van deze gevallen is essentieel om de impact voor klanten te beperken.

Om deze cascade te voorkomen, wordt de prioriteit omgedraaid: voorafgaand aan elke reboot van een regio wordt een diepgaande analyse van de afhankelijkheden van interne services uitgevoerd. Sommige interne diensten worden live gemigreerd. Hun virtuele machines worden live verplaatst naar reeds gepatchte hosts, de afhankelijkheidsketen wordt beschikbaar gehouden en vervolgens wordt de host vrijgegeven voor een reboot.Deze procedure is langdurig en verbruikt intensief materiële en menselijke middelen. Deze moet worden beperkt tot een klein aantal virtuele machines om de doelstelling te halen de migratie in de tijd te beperken.Sommige workloads vereisen bijzondere aandacht: in het bijzonder de diensten van Cloud Databases (DBaaS), de interne Datalake en de functies voor

Observability

worden

één VM per keer

gemigreerd, zonder meer dan één machine tegelijk uit te schakelen, waarbij de update van hun hosts zo lang mogelijk wordt uitgesteld. Deze soepele migratie helpt cascade-storingen in de diensten te voorkomen en zorgt ervoor dat de tools die de operaties ondersteunen beschikbaar blijven.Technische incidenten en aanpassingen tijdens de operatieEen operatie van deze omvang verloopt niet zonder incidenten. Tijdens de campagne zijn verschillende technische problemen tegengekomen en opgelost.VM's die niet herstarten na een host-rebootHet eerste grote incident deed zich voor tijdens de eerste Europese golf: virtuele machines herstartten niet na de reboot van hun hypervisor. Nova compute meldde "Instance shutdown by itself" zonder synchronisatie. De

bronoorzaak

werd op de tweede dag geïdentificeerd: de libvirt-guests-service raakte in conflict met nova compute en stopte de instances bij de reboot zonder sync aan de API-kant. De toegepaste correctie is het uitschakelen en maskeren van libvirt-guests.service op de hosts vóór de reboot. Vanaf deze fix werken de automatische herstarts van de VM's.Gegevenscorruptie bij synchrone dienstenOp de avond van de tweede dag meldde het interne monitoringsysteem beschadigde gegevens op meerdere VM's verspreid over 3 clusters. De waarschijnlijke oorzaak: de geforceerde reboot vond plaats midden in een schijfschrijfactie. De

graceful shutdown

wordt vervolgens verlengd naar 60 seconden vóór de geforceerde kill, om de schrijfacties de tijd te geven om te voltooien. Er is een script voor het automatisch herstarten van VM's die uitgeschakeld bleven, geïmplementeerd.Deadlock-API in ParijsIn de nacht van de tweede op de derde dag kwamen de Nova- en Neutron-API's in Parijs in een wederzijdse deadlock terecht: de Neutron-API (gelimiteerd tot 10 processen) raakte verzadigd door een vlaag van verzoeken van Nova, waardoor gedurende ongeveer twee uur HTTP 503-fouten werden geretourneerd. De oplossing bestaat uit het verhogen van de Neutron-

workers

van 10 naar 30 en de Apache-processen van 10 naar 32. De B-zones van Parijs en Milaan worden uitgesteld om de tijd te nemen voor stabilisatie.

Verzadiging support in BHS

Op de site van BHS (Canada) bereikte het API-verkeer

10 keer het gebruikelijke maximale verkeer, wat de Manager en de support verzadigde. Klanten ontdekten de impact voordat ze de communicatie hadden ontvangen. Dit geval illustreert concreet de kettingreacties binnen de infrastructuur.Deze bugs en problemen die werden aangetroffen, zijn allemaal beheerd in het kader van de operaties, maar zullen in aanmerking worden genomen om de passende verbeteringen op duurzame wijze door te voeren.Reboots en hardware-interventiesEen reboot van tienduizenden machines heeft ook een hardwarematige dimensie. Er is een inherent uitvalpercentage bij elke server-reboot. Tijdens de eerste nacht kwamen ongeveer

20 tot 30 hosts van de 6.000 niet uit zichzelf terug: defecte geheugenmodules, BIOS-configuratie, inactieve netwerkinterface. In de Verenigde Staten vereisten verschillende hosts het verwijderen van de CMOS-batterij

• en het ontladen van de voeding voor een herstart — een terugkerend hardwareprofiel.Elke locatie beschikt over
• datacentrumtechnici die tijdens de campagne als versterking worden ingezet. Hun rol:
• met spoed ingrijpen op de hosts die niet opnieuw opstarten en door de orchestrators worden gesignaleerd;defecte onderdelen vervangen (schijven, geheugenmodules, voedingen);

fysieke handelingen uitvoeren die geen enkel hulpmiddel kan automatiseren: harde reboot

, controle van indicatielampjes, interventie in de rack.

De datacentrumtechnici werken in de

modus voor prioritaire interventie op falende hosts

, in coördinatie met de Run/SRE-teams die prioriteiten stellen op basis van de klantblootstelling van de host. Een host die kritieke instanties draait en niet terugkeert, krijgt voorrang op een lege host. Deze kruisprioritering — softwarematig en fysiek — is wat het tempo van de operatie handhaaft.Communicatie en ondersteuning: de getroffen klanten informerenEen eenzijdige patching met gecontroleerde impact is ondenkbaar zonder een evenredige communicatie-inspanning.

Gerichte en stapsgewijze communicatieGezien de dynamiek van 'follow the sun' zou een globale en ongedifferentieerde communicatie geen enkele zin hebben gehad. De gekozen strategie was een gerichte en stapsgewijze communicatie: uitsluitend gericht aan klanten van wie de instanties worden gehost op de hosts die voor een reboot zijn gepland, en geactiveerd naarmate de operatie vorderde, regio per regio, golf per golf.Aanvankelijk werd besloten om

geen openbare statuspagina te activeren

, om de implementatievolgorde niet bloot te leggen. De communicatie verloopt via

gerichte communicatie via ons Support-portaal, met het versturen van e-mails naar klanten met een Business- en Enterprise-supportniveau.Constatering: sommige berichten worden niet afgeleverdCommunicatiemiddelen hebben technische beperkingen. Voor regio's met een hoog volume zoals GRA6 (bijna 90.000 niet-gecontacteerde klanten) wordt het massaal versturen van e-mails uitgesloten om een toename van supporttickets te voorkomen.Gezien deze constatering wordt op de tweede dag een draai gemaakt: het implementeren van een

conditionele banner in de Manager

via

feature flipping — als de ingelogde gebruiker in de lijst met getroffen klantaccounts (NIC's) staat, wordt er een informatiebericht weergegeven. De ontwikkeling wordt gedurende de dag uitgevoerd en de banner wordt op de derde dag ingezet. Er wordt op dat moment ook een Public Cloud-statuspagina aangemaakt.Ondanks deze maatregelen hebben sommige berichten hun ontvangers niet bereikt: verouderde contactadressen, gefilterde meldingen, tijdsverschil tussen de geplande reboot en het tijdstip van verzending. Klanten ontdekten de impact zonder dat zij vooraf waren gewaarschuwd. Deze knelpunten zijn na afloop van het initiële mitigatieplan geïdentificeerd als prioritaire verbeterpunten.Support als laatste redmiddelVoor klanten die niet waren geïnformeerd of om verduidelijking vroegen, werd de

klantenservice

Perspectieven

De CVE-2026-53359 bracht onze klanten en onze infrastructuren in gevaar. Het mitigatieactieplan leidde tot een klantimpact — beperkt, gesequenced, aangekondigd, maar reëel. Gedetailleerder communiceren tijdens de uitvoering van het actieplan, zolang de infrastructuur niet gepatcht was, zou het risico voor onze klanten aanzienlijk hebben vergroot door sommigen van hen aan te moedigen de publiekelijk beschikbare exploit te "testen".

Het heropstarten van een wereldwijd machinepark met nul impact was geen haalbaar doel. Het doel was dus de kleinst mogelijke impact die verenigbaar is met de veiligheid van het gehele park.

Het patchen en herstarten van alle Public Cloud- en VPS-hosts was nog nooit eerder onder deze tijdsdruk uitgevoerd. Deze noodprocedure werd ingevoerd vanwege het risico dat aan de kwetsbaarheid verbonden was. Eerdere gevallen werden altijd afgehandeld door een geleidelijke herstart, waarbij gebruik werd gemaakt van de natuurlijke rotatiesnelheid van de virtuele machines op de infrastructuur, gecombineerd met ad-hoc live-migraties die over een lange periode waren gepland.

De teams die bij deze operatie betrokken waren, hebben een topprestatie geleverd met een zeer redelijk aantal storingen en een beperkte impact op de klant in verhouding tot de omvang van het project. Omdat we ons echter bewust zijn van het feit dat de komende maanden tot meer publicaties over kernelkwetsbaarheden kunnen leiden, lijkt het vast te staan dat deze noodprocedure herhaald zal moeten worden. We zullen de volgende keer beter moeten presteren, zowel wat betreft het beheersen van de bruto-impact van de herstarts als wat betreft het vooraf informeren van klanten en de procedure voor het ondersteunen van klanten die tijdens de operaties getroffen zijn. Daarom zullen we in de komende dagen en weken de voornaamste gevolgen identificeren voor onze klanten die complexe storingen hebben ondervonden, en zullen we de problemen die tijdens de operaties zijn opgetreden intern evalueren in een post-mortem, met als doel onze procedures in de toekomst te verbeteren.