Retour d’expérience sur une opération de correction conduite en une semaine sur l’ensemble de notre parc KVM, selon une stratégie de patching dont l’objectif central fut de minimiser l’impact sur les services de nos clients.

Une vulnérabilité dans le sous-système de virtualisation

Le mardi 7 juillet, en début d’après-midi, une alerte de sécurité est remontée concernant la CVE-2026-53359, une vulnérabilité de type use-after-free affectant le sous-système de shadow-paging de KVM x86 dans le noyau Linux. La faille, vieille de plusieurs années, est rendue publique le 6 juillet ; des blogs d’autres fournisseurs cloud apparaissent dès le 7.

KVM constitue le moteur de virtualisation sur lequel repose l’immense majorité des instances hébergées chez OVHcloud. Le mécanisme est le suivant : lorsqu’une modification externe d’un Page Directory Entry (PDE) survient, l’entrée RMAP peut conserver une référence vers une page mémoire déjà libérée. Le noyau déréférence ensuite cette page obsolète, ce qui peut entraîner un plantage de l’hyperviseur ou, dans les scénarios les plus défavorables, une élévation de privilège côté hôte. L’exploit est reproductible : un test interne sur un hôte non patché provoque un crash en environ deux minutes.

L’ensemble des noyaux Linux x86 antérieurs au commit de correctif est concerné, sans distinction de distribution. Le patch officiel est backporté sur nos noyaux de production Debian.

3 risques principaux sont à considérer :

• Un client VPS utilise l’exploit pour crasher le host qui fait fonctionner sa machine virtuelle : crash et reboot non contrôlé de plusieurs centaines de machines virtuelles client.
• Scénario identique sur les instances du Public Cloud, l’impact est similaire mais le nombre de machines virtuelles par host est plus restreint et les machines virtuelles sont plus puissantes et utilisées pour des systèmes plus sensibles (bases de données, gestionnaire de queues, load balancer, etc.). Ces systèmes sont souvent utilisés dans des architectures applicatives composites avec des dépendances complexes.
• Probabilité de la publication à venir d’un exploit de prise de contrôle du host, ce qui augmenterait immédiatement le niveau de risque à un niveau inacceptable en raison de l’impact sur la confidentialité des données clients et de l’intégrité de l’infrastructure.

Pour OVHcloud, le périmètre représente des dizaines de milliers de serveurs hôtes hyperviseurs, hébergeant environ un million de machines virtuelles. La question n’est donc pas de déterminer s’il faut patcher, mais comment mener cette opération à une telle échelle, en sachant qu’un impact client nul n’est pas atteignable.

Les options sur la table pour mitiger le risque

1 : Attendre les noyaux patchés officiels

Cette option nous rendait tributaire d’un agenda tiers qui nous laissait en statut de risque pour une période non maîtrisée. Nous l’avons écartée rapidement au regard du risque.

2 : Live patch

Appliquer un live patch nécessite d’autoriser ce type d’opération dans la configuration du noyau, ce qui permet, par construction, de pouvoir modifier son comportement à la volée, entraînant par la même une réduction de son niveau de durcissement, limitant les capacités de détection en cas de compromission de celui-ci. Par ailleurs, le live patch est une procédure sensible par nature, pouvant déboucher sur un statut instable à l’échelle du parc. C’est une option qui permet de gagner du temps en attendant une solution pérenne. Nous avons décidé de ne pas faire ce compromis qui aurait augmenté très fortement le risque en cas de publication d’exploit de prise de contrôle du host.

3 : Mitigation par désactivation de la virtualisation imbriquée

Désactiver la virtualisation imbriquée sur les hosts permet de rendre l’exploit inopérant. Nous n’avons pas de visibilité sur l’utilisation de cette fonctionnalité par nos clients, donc il est impossible de déterminer l’impact sur les services clients, et cette fonctionnalité est nécessaire pour conserver la capacité de migration live d’une instance d’un host physique à un autre. Nous écartons cette piste rapidement.

4 : Live migrate

Organiser une migration live des machines virtuelles, depuis des host vulnérables vers des hosts vides qui ont été patchés entre temps. Cette option est très satisfaisante en termes de continuité de service car la migration se fait sans impact sur les machines virtuelles, à l’exception de performances réduites pendant la migration. Cette option prend beaucoup de temps, en raison de la copie des machines virtuelles de host à host ; elle n’est pas réalistiquement utilisable à l’échelle du parc et du souhait de protéger nos clients en quelques jours plutôt que plusieurs mois. Nous décidons de conserver cette option pour certaines machines virtuelles critiques uniquement, chaque migration live provoquant un délai important dans le déroulement des batchs.

5 : Backport du patch sur nos noyaux et reboot de tous les hosts

C’est finalement cette option qui sera retenue et qui va être détaillée dans la suite de l’article.

Mardi après-midi : déclenchement et organisation de la cellule de crise

Dès la confirmation de la vulnérabilité, la priorité est de construire une réponse structurée et coordonnée ; les analystes en charge de cette première analyse comprennent très rapidement les enjeux des jours à venir. L’information est diffusée en interne en début d’après-midi. Plusieurs espaces de coordination sont ouverts : un pour la coordination technique, un pour la coordination de crise, un pour les opérations US, un pour la communication client et le support. Dans le même temps, les équipes Kernel préparent et backportent le correctif ; le premier noyau patché est livré en soirée.

Les tests de validation sont menés en environnement de test dans la soirée. Le patch est confirmé, l’exploit ne crashe plus les hyperviseurs patchés et les tests de QA passent avec le noyau patché.

La cellule de crise évolue vers un suivi du déploiement et est ensuite pilotée par le NOC (Network Operations Center), qui assume le rôle de coordinateur opérationnel : suivi de l’avancement global, arbitrage des priorités entre régions et services, maintien de la vision d’ensemble. L’exécution est portée par les experts Public Cloud et VPS, qui opèrent les reboots, live-migrate et contraintes d’anti-affinité. La séparation entre coordination et exécution est volontaire : le NOC coordonne, les équipes opérationnelles agissent et remontent les métriques et évènements techniques nécessaires à la coordination.

La synchronisation avec le Support client (état d’avancement en temps réel pour répondre aux clients impactés) et les équipes Sécurité (veille sur la vulnérabilité, validation du périmètre et des critères de fin d’opération) est assurée en continu.

L’opération s’inscrivant en follow the sun, la cellule fonctionne en 24/7 avec une rotation par zone géographique. Trois points de synchronisation sont tenus chaque jour, couvrant les transitions de zones. Ceux-ci rassemblent le NOC, les experts opérationnels, le Support et la Sécurité pour : partager l’état d’avancement par région, transmettre le relais entre zones (ce qui a fonctionné, les ajustements de procédure sur la base des retours terrain), et arbitrer les priorités de la prochaine séquence.

La cellule complète réunit, par rotation 24/7 : les équipes Kernel & Virtualization (analyse du correctif, backport, validation), VPS et Public Cloud (déploiement), NOC (pilotage), Run & SRE (orchestration, anti-affinité, live migration), Datacenter Operations (interventions matérielles), Support client (sollicitations clients), Sécurité (veille, périmètre, fin d’opération) et Communication (transparence, notifications ciblées).

L’objectif assigné est clair : patcher et rebooter les hôtes concernés dans les meilleurs délais afin de réduire la fenêtre de vulnérabilité, en minimisant l’impact sur les services. La contrainte principale tient à l’échelle : des dizaines de milliers de machines à traiter, sur l’ensemble des continents, sachant qu’une prise en charge au cas par cas est matériellement impossible à ce volume.

Le risque principal à cette étape est l’exploitation de la vulnérabilité, entraînant un crash du host non patché. La cellule de crise décide d’appliquer le patch globalement en amont de la phase de redémarrage. Dans le cas d’une exploitation de la vulnérabilité, le crash d’un host entraînera son redémarrage et la prise en compte automatique du patch. Par ailleurs, il existe un risque que la CVE soit exploitée pour une prise de contrôle malveillante du host. Aucun code d’exploitation n’est disponible publiquement, mais nous savons que ce n’est qu’une question de temps avant qu’un chercheur réussisse à utiliser la vulnérabilité pour prendre le contrôle du host. Ce scénario étant catastrophique, nous savons que chaque minute compte.

Une décision assumée : un patching unilatéral à impact contrôlé

Le Comité Exécutif valide le Go/No-Go en soirée : la première région sera traitée le lendemain matin. Pour ce nombre de machines, aucun scénario sans impact n’existe. Négocier une fenêtre de maintenance avec chaque client, vérifier chaque dépendance, orchestrer chaque reboot sur mesure — autant d’étapes matériellement incompatibles avec un délai acceptable au regard du risque de sécurité.

La cellule de crise prend donc une décision assumée : un patching unilatéral à impact contrôlé, appliqué sans attendre l’accord individuel de chaque client, en sachant que certains services subiront une interruption. Le raisonnement tient en trois points :

• ne pas patcher expose l’ensemble du parc à une faille de sévérité élevée ;
• un traitement au cas par cas allongerait les délais et laisserait la majorité des hôtes vulnérables pendant des semaines ;
• une action rapide et globale protège le plus grand nombre, quitte à impacter une minorité de manière temporaire.

La priorité n’est alors plus d’éviter l’impact, mais de le minimiser, le diluer et le rendre prévisible. C’est cette ligne qui structure l’ensemble de l’opération : follow the sun, priorisation des régions et planification anti-affinité.

Mercredi 8 juillet : démarrage depuis Sydney

Le choix de Sydney pour tester le déploiement est trivial : le nombre de hosts est limité, et la plage de déploiement en HNO local (pendant la nuit) correspond aux horaires de bureaux des équipes en Europe. Démarrer par la région la plus à l’est permet :

• d’opérer sur la zone la moins chargée ;
• de valider la procédure en conditions réelles, à échelle réduite, avant industrialisation ;
• de collecter les premiers retours avant de lancer les régions européennes et nord-américaines.

Les premières vagues de patch + reboot sont appliquées sur les hôtes VPS en Australie. La région SYD2 est terminée en début d’après-midi (heure de Paris), sans incident. Les procédures sont adaptées sur la base des retours de terrain.

Dès que la procédure est stabilisée, le follow the sun est engagé : chaque région prend le relais à son tour, sur sa matinée locale, en transmettant le contexte à la suivante. La première vague européenne (RBX, GRA6, WAW, DE, SBG, MIL, UK) est lancée le soir même, à 18h30 heure de Paris.

Deux périmètres, deux expositions : VPS d’abord, Public Cloud ensuite

Le déploiement n’est pas uniforme. VPS et Public Cloud diffèrent par leur architecture comme par leur exposition client. Le nombre de machines virtuelles sur des host VPS est plus important et de nombreuses entreprises et particuliers utilisent des VPS pour des infrastructures de test ; la probabilité d’un test client du code d’exploitation sur sa machine virtuelle est très élevée et l’impact l’est également en raison du nombre de machines virtuelles sur chaque host.

Sur le VPS, le périmètre par hôte est contenu et l’impact client par reboot reste maîtrisé. Les lots peuvent être enchaînés rapidement, ce qui permet de sécuriser une grande partie du parc dès les premières 24 heures.

Le Public Cloud présente une exposition d’un autre ordre. Une région concentre des milliers de clients, et un hôte peut héberger des instances critiques. Les régions les plus importantes comptent des centaines voire des milliers de hosts avec des infrastructures client virtuelles complexes. Nous décidons de prioriser :

• par taille de région : les régions à plus faible densité sont traitées en premier, afin de valider la robustesse de la procédure à l’échelle ;
• par nombre de clients exposés : les régions à fort volume sont orchestrées avec une granularité plus fine, lot par lot, pour diluer le risque.

Seuils d’arrêt et contrôle du tempo

Chaque vague de reboots est soumise à un seuil d’arrêt : si le nombre d’hôtes en panne simultanée dépasse un seuil défini, la vague est suspendue. Ce seuil est fixé à 15 hôtes pour les régions à forte densité (GRA, RBX, BHS) et à 5 hôtes pour les autres. Un arrêt est également déclenché à 06h00 ou sur demande du datacentre local.

Ce dispositif permet de ne pas aggraver une situation de panne matérielle en continuant à rebooter des hôtes que les techniciens DC n’ont pas encore pu traiter. Il introduit un point de régulation entre l’automatisation logicielle et la réalité physique du terrain.

Ne pas rebooter simultanément deux instances d’un même projet : l’anti-affinité comme garde-fou

Le principal risque pour nos clients lors d’une telle opération n’est pas le reboot lui-même, c’est l’interruption simultanée de plusieurs instances d’un même projet garantissant une résilience applicative capable de faire face à une défaillance du fournisseur. Un client qui a réparti ses charges de travail sur plusieurs hôtes pour assurer sa haute disponibilité ne doit pas voir l’ensemble de ses instances basculer en même temps. La décision a été prise d’aller au-delà du respect des règles d’anti-affinité qui ont pu être définies dans les déploiements clients.

Ainsi, pour chaque projet client disposant d’instances réparties sur plusieurs hôtes, nos orchestrateurs calculent un graphe de co-localisation. À aucun moment, deux hôtes portant des instances du même projet ne sont rebootés dans la même fenêtre : des vagues mutuellement exclusives sont définies, et un hôte doit être de retour en service avant le lancement du suivant dans la même classe d’anti-affinité.

Cette anti-affinité est appliquée en best effort : elle est respectée dans la majorité des cas, mais ne peut être garantie à 100 % sur l’ensemble du parc. L’objectif reste de séquencer l’impact pour qu’il soit absorbable côté applicatif. Les clients dont toutes les instances reposent sur un seul hôte subissent une interruption ponctuelle, dont la fenêtre est annoncée.

Live-migration prioritaire des services et workloads sensibles

Derrière chaque instance client se trouvent des contrôleurs, des API, des plans de données, des bases internes. Un reboot non maîtrisé des hôtes qui portent ces services créerait des deadlocks : un service interne indisponible bloque la suite des reboots, qui bloque le patching. Par ailleurs, certains services OVHcloud reposent sur des machines virtuelles hébergées sur les instances Public Cloud. Prendre en compte ces cas est indispensable pour limiter les impacts clients.

Afin d’éviter cette cascade, la priorité est inversée : une analyse en profondeur des dépendances des services internes est faite en amont de chaque reboot de région. Certains services internes sont live-migrés. Leurs machines virtuelles sont déplacées à chaud vers des hôtes déjà patchés, la chaîne de dépendances est maintenue disponible, puis l’hôte est libéré pour reboot.

Cette procédure est longue et consomme intensivement des ressources matérielles et humaines. Elle doit être limitée à un nombre réduit de machines virtuelles pour respecter l’objectif de contenir dans le temps la migration.

Certains workloads requièrent une attention particulière : en particulier les services de Cloud Databases (DBaaS), le Datalake interne et les fonctions d’Observability sont migrés une VM à la fois, sans éteindre plus d’une machine simultanément, en différant la mise à jour de leurs hôtes le plus longtemps possible. Cette migration en douceur permet d’éviter les pannes en cascade sur les services et d’assurer que les outils en support des opérations restent disponibles.

Incidents techniques et ajustements en cours d’opération

Une opération de cette ampleur ne se déroule pas sans incident. Plusieurs problèmes techniques ont été rencontrés et résolus en cours de campagne.

VMs ne redémarrant pas après reboot d’hôte

Le premier incident majeur est apparu dès la première vague européenne : des machines virtuelles ne redémarraient pas après le reboot de leur hyperviseur. Nova compute signalait des « Instance shutdown by itself » sans synchronisation. La cause racine est identifiée le deuxième jour : le service libvirt-guests entrait en conflit avec nova compute et stoppait les instances au reboot sans sync côté API. Le correctif appliqué est de désactiver et masquer libvirt-guests.service sur les hôtes avant reboot. À partir de ce fix, les redémarrages automatiques des VMs fonctionnent.

Corruption de données sur les services synchrones

Le soir du deuxième jour, le système de monitoring interne signale des données corrompues sur plusieurs VMs réparties sur 3 clusters. La cause probable : le reboot forcé intervenait en plein milieu d’écriture disque. Le graceful shutdown est alors étendu à 60 secondes avant kill forcé, pour laisser le temps aux écritures de se terminer. Un script de redémarrage automatique des VMs restées éteintes est mis en place.

Deadlock API à Paris

Dans la nuit du deuxième au troisième jour, les API Nova et Neutron à Paris entrent en deadlock mutuel : l’API Neutron (plafonnée à 10 process) sature sous une rafale de requêtes de Nova, renvoyant des HTTP 503 pendant environ deux heures. Le fix consiste à augmenter les workers Neutron de 10 à 30 et les process Apache de 10 à 32. Les zones B de Paris et Milan sont reportées le temps de stabiliser.

Saturation support à BHS

Sur le site de BHS (Canada), le trafic API atteint 10 fois le trafic maximal habituel, saturant le Manager et le support. Des clients ont découvert l’impact avant d’avoir reçu la communication. Ce cas illustre concrètement les réactions en chaîne au sein de l’infrastructure.

Ces bugs et problèmes rencontrés ont tous été gérés dans le cadre des opérations mais seront pris en compte pour mettre en place les améliorations adaptées de manière pérenne.

Les reboots et les interventions matérielles

Un reboot de dizaines de milliers de machines implique aussi une dimension matérielle. Il existe un taux de panne inhérent à tout reboot de serveur. Sur la première nuit, environ 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls : barrettes mémoire défaillantes, configuration BIOS, interface réseau inactive. Aux États-Unis, plusieurs hôtes ont nécessité un retrait de la batterie CMOS et un drain d’alimentation avant repower — un profil matériel récurrent.

Chaque site dispose de techniciens datacentre mobilisés en renfort pendant la campagne. Leur rôle :

• intervenir en urgence sur les hôtes en échec de reboot signalés par les orchestrateurs ;
• remplacer les pièces défectueuses (disques, barrettes mémoire, alimentations) ;
• effectuer les gestes de proximité qu’aucun outil ne peut automatiser : hard reboot physique, vérification des voyants, intervention en baie.

Les techniciens datacentre opèrent en mode intervention prioritaire sur les hôtes en échec, en coordination avec les équipes Run/SRE qui priorisent selon l’exposition client de l’hôte. Un hôte qui porte des instances critiques et ne revient pas passe avant un hôte vacant. Cette priorisation croisée — logicielle et physique — est ce qui maintient le tempo de l’opération.

Communication et support : informer les clients impactés

Un patching unilatéral à impact contrôlé ne peut se concevoir sans un effort de communication proportionné.

Une communication ciblée et progressive

Face à la dynamique du follow the sun, une communication globale et indifférenciée n’aurait eu aucun sens. La stratégie retenue a été une communication ciblée et progressive : adressée uniquement aux clients dont les instances sont hébergées sur les hôtes programmés pour reboot, et déclenchée au fur et à mesure de l’avancée de l’opération, région par région, vague par vague.

Initialement, la décision est prise de ne pas activer de status-page publique, pour ne pas exposer la séquence de déploiement. Les communications passent par des targeted communications via notre portail Support, avec envoi d’emails aux clients ayant un niveau de Support Business et Enterprise.

Constat : certains messages ne sont pas délivrés

Les outils de communication ont des limites techniques. Pour les régions à fort volume comme GRA6 (près de 90 000 clients non contactés), l’envoi massif d’emails est écarté pour éviter la multiplication de tickets support.

Face à ce constat, un pivot est décidé au deuxième jour : implémenter une bannière conditionnelle dans le Manager via un feature flipping — si l’utilisateur connecté figure dans la liste des comptes client (NICs) impactés, un message d’information s’affiche. Le développement est mené dans la journée et la bannière est déployée le troisième jour. Une status-page Public Cloud est également créée à ce moment.

Malgré ces dispositifs, certains messages n’ont pas atteint leurs destinataires : adresses de contact obsolètes, notifications filtrées, décalage entre l’heure prévue du reboot et l’heure d’envoi. Des clients ont découvert l’impact sans en avoir été avertis au préalable. Ces points de rupture sont identifiés comme des axes d’amélioration prioritaires à l’issue du plan de mitigation initial.

Le support comme canal de dernier recours

Pour les clients non informés, ou en demande de précisions, le support client a été renforcé et préparé : briefing en amont sur le contexte de l’opération, accès en temps réel à l’état d’avancement par région et par hôte, traitement accéléré des tickets liés à la campagne via un circuit dédié.

Le support rattrape ce que les notifications automatisées n’ont pas pu porter. Il ne remplace pas la communication, il en compense certains des manques.

Timeline de l’opération

Perspectives

La CVE-2026-53359 mettait nos clients et nos infrastructures à risque. Le plan d’action de mitigation a entraîné un impact client — contenu, séquencé, annoncé, mais réel. Communiquer de manière plus détaillée pendant l’exécution du plan d’action, tant que l’infrastructure n’était pas patchée, aurait augmenté significativement le risque pour nos clients, en poussant certains d’entre eux à « tester » l’exploit disponible publiquement.

Rebooter un parc d’envergure mondiale avec un impact nul n’était pas un objectif atteignable. L’objectif était donc la plus faible ampleur d’impact compatible avec la sécurité de l’ensemble du parc.

Patcher et redémarrer tous les hosts Public Cloud et VPS n’avait jamais été fait avec cette contrainte de temps. Cette procédure d’urgence a été mise en place au regard du risque lié à la vulnérabilité. Les cas précédents ayant toujours été traités par un reboot progressif en utilisant le taux de rotation naturel des machines virtuelles sur l’infrastructure, combiné à des live-migrate ad-hoc planifiées sur un temps long.

Les équipes impliquées dans cette opération ont réalisé un exploit avec un nombre de pannes et d’impact client très raisonnable en proportion de la taille du chantier. Cependant, conscients que les prochains mois pourraient donner lieu à d’autres publications de vulnérabilité kernel, il semble établi que cette procédure d’urgence va devoir se répéter. Nous devrons faire mieux la prochaine fois, aussi bien dans la maîtrise de l’impact brut des redémarrages que dans l’information en amont des clients et dans la procédure d’accompagnement des clients impactés lors des opérations. Ainsi, dans les jours et semaines à venir, nous allons identifier les impacts principaux chez nos clients ayant subi des pannes complexes, et travailler les problèmes rencontrés pendant les opérations en interne, en post mortem, dans le but d’améliorer nos procédures à l’avenir.