Suite à la faille KVM, OVHcloud fait le bilan de sa migration monstre Première fois, mais pas la dernière Illustration : Flock Vincent Hermann Le 23 juillet à 11h14 Dans un billet de blog, l’entreprise explique comment l’apparition d’une faille critique dans le moteur de virtualisation KVM a entrainé une vaste campagne de mises à jour dans ses infrastructures. Elle a choisi une approche radicale, avec un impact assumé sur les clients, prévenus en amont. Une erreur ?
L’incident débute le 6 juillet, quand les détails d’une faille critique apparaissent. Estampillée CVE-2026-53359 et surnommée Januscape, elle réside dans le code de shadow paging du moteur de virtualisation KVM sur l’architecture x86. « 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 », explique OVHcloud dans son billet.
Le lendemain, OVHcloud déclenche une cellule de crise pour aborder la situation, avec la question centrale : comment mettre à jour des dizaines de milliers de serveurs hôtes hyperviseurs, représentant environ un million de machines virtuelles ? Cinq solutions, aucune idéale Comme l’entreprise l’explique dans son billet, cinq possibilités étaient sur la table. Elle pouvait attendre l’arrivée des noyaux Linux officiels mis à jour, mais elle aurait été alors « tributaire d’un agenda tiers ».
Un live patch ? Une opération « sensible par nature », qui permet de gagner du temps mais entraine aussi une réduction du niveau de durcissement et une baisse des capacités de détection en cas de compromission. OVHcloud a considéré rapidement la désactivation de la virtualisation imbriquée, qui permet notamment de lancer des machines virtuelles à l’intérieur d’autres machines virtuelles.
La solution est écartée, faute de pouvoir mesurer l’impact sur les clients. Une piste plus sérieuse était la migration live, depuis des hôtes vulnérables vers d’autres vides et patchés. L’option est décrite comme « très satisfaisante » pour la continuité, sans impact sur les machines virtuelles.
Elle a toutefois un sérieux désavantage : elle prend beaucoup de temps. OVHcloud la garde sous le coude pour certaines machines critiques. La solution adoptée consiste finalement à mettre les mains dans le cambouis, en intégrant soi-même le patch dans les noyaux utilisés, en diffusant ces derniers et en redémarrant la totalité des hôtes.
Un « patching unilatéral à impact contrôlé » Le choix de cette solution est « assumé », selon OVHcloud. Elle affirme qu’il s’agissait de la seule solution possible pour tenir compte des paramètres : la criticité de la faille, le nombre de machines à traiter et le degré de perturbation pour les clients. « Une action rapide et globale protège le plus grand nombre, quitte à impacter une minorité de manière temporaire », ajoute OVHcloud.
Tout s’est très vite enchainé. Le soir du 7 juillet, le « backport » du correctif est réalisé dans le noyau et les tests de validation commencent. Dans les heures qui suivent, les équipes confirment que le noyau mis à jour n’est plus sensible à la faille.
Dans la foulée, le comité exécutif donne son feu vert pour un déploiement dès le lendemain matin. OVHcloud n’a cependant pas déclenché ce déploiement sur la totalité des machines virtuelles au même instant. L’opération commence dans la région Sydney, avec plusieurs avantages : le nombre d’hôtes est limité, la plage de déploiement correspond aux heures de bureau en France et l’entreprise pourra collecter les premiers retours, avant de se tourner vers des déploiements plus importants.
Le 8 juillet, en début d’après-midi (heure de Paris), tous les hôtes VPS (Virtual Private Server) de la région sont mis à jour et redémarrés. L’entreprise suit littéralement le soleil : « Chaque région prend le relais à son tour, sur sa matinée locale, en transmettant le contexte à la suivante ». Elle estime avoir récolté assez de retours pour lancer la première vague européenne sur les VPS (RBX, GRA6, WAW, DE, SBG, MIL, UK) à 18h30, toujours le 8 juillet.
À chaque fois, les VPS sont migrés les premiers, l’offre Public Cloud présentant d’autres défis. Les régions à plus faible densité sont traitées d’abord, tandis que celles à fort volume sont « orchestrées avec une granularité plus fine, lot par lot, pour diluer le risque ». Plusieurs mécanismes ont été mis en place pour limiter les risques pendant les opérations, notamment des seuils d’arrêt.
Chaque vague de redémarrages était bornée par un seuil d’arrêt automatique : 15 hôtes en panne simultanée pour les régions à forte densité (GRA, RBX, BHS), 5 hôtes pour les autres, avec arrêt systématique à 06h00 locales ou sur demande du centre de données. Ce mécanisme vise à ne pas superposer des redémarrages supplémentaires à une situation de panne matérielle déjà en cours de traitement. Les orchestrateurs ont en outre calculé un graphe de co-localisation par projet et ont défini des vagues mutuellement exclusives.
Ainsi, deux hôtes portant des instances du même projet ne sont jamais redémarrés dans la même fenêtre, un hôte devant être revenu en service avant le lancement du suivant dans la même classe. Cette règle est appliquée en « best effort », non garantie à 100 % sur l’ensemble du parc. Source : OVHcloud Des incidents quand même Malgré les précautions, des problèmes sont quand même apparus.
Certaines machines virtuelles n’ont pas redémarré après le reboot de leur hôte, dès la première vague européenne. Un conflit a été détecté entre libvirt-guests.service et Nova Compute, provoquant l’arrêt des instances sans synchronisation API. Dès le deuxième jour, un problème de corruption de données est apparu sur des services synchrones.
Des machines virtuelles réparties sur trois clusters ont présenté des données corrompues, à cause probablement d’un redémarrage forcé en pleine écriture disque. La période d’attente avant kill forcé a été étendue à 60 secondes, et un script de redémarrage automatique des VM restées éteintes a été déployé. À Paris, dans la nuit du deuxième au troisième jour, des soucis de saturation mutuelle sont apparus entre les API Nova et Neutron.
Cette dernière plafonnant à 10 processus, la situation a provoqué deux heures de panne HTTP 503. Le correctif appliqué a consisté à augmenter le nombre de workers Neutron de 10 à 30 et celui des processus Apache de 10 à 32. Sur le plan matériel, environ 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls après la première nuit de redémarrages (barrettes mémoire défaillantes, configuration BIOS, interfaces réseau inactives), indique OVHcloud.
Certains cas aux États-Unis ont même nécessité un retrait de la batterie CMOS et un drain d’alimentation. Des techniciens ont été mobilisés en renfort sur chaque site pour intervenir en priorité sur les hôtes en échec. En tout, l’opération s’est étalée sur 11 jours.
Ce type d’opération se reproduira, assure OVHcloud Côté communication aux clients, la stratégie retenue a été l’envoi de messages ciblés de manière progressive, déclenché région par région et vague par vague, aux seuls clients concernés par les hôtes programmés. Le choix initial de ne pas ouvrir de page publique de statut visait à ne pas exposer la séquence de déploiement, un arbitrage voulu entre transparence et risque (éviter d’inciter des clients à tester l’exploit). Les limites de ce dispositif sont pointées par OVHcloud : pour GRA6 (près de 90 000 clients non contactés), l’envoi massif d’e-mails a été écarté pour ne pas saturer le support, ce qui a conduit à un pivot vers une bannière conditionnelle dans le Manager (basée sur une liste de comptes impactés) le lendemain et – finalement – la création d’une page de statut Public Cloud le jour suivant.
En revanche, malgré les détails fournis par l’entreprise, le descriptif est essentiellement qualitatif : on ne connait pas le nombre total d’incidents clients, la durée cumulée d’indisponibilité, ni les éventuelles compensations. L’entreprise indique en tout cas avoir tiré des enseignements de cette migration, car elle n’avait jamais été confrontée à une situation critique d’une telle ampleur, les épisodes précédents ayant été traités par rotation naturelle du parc combinée à des migrations live planifiées sur une durée longue. OVHcloud se veut claire également : ce type de procédure d’urgence est amené à se reproduire compte tenu du rythme des publications de vulnérabilités noyau, sous l’impulsion de l’IA générative notamment.
Les axes d’amélioration identifiés par l’entreprise portent sur trois points : la maîtrise de l’impact brut des redémarrages, l’information en amont des clients, et la procédure d’accompagnement des clients impactés. L’entreprise évoque donc un « exploit » réalisé par ses équipes, mais ajoute : « 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 ». Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker.
Soutenez le journalisme tech de qualité en vous abonnant. Accédez en illimité aux articles d'un média expert Profitez d'au moins 1 To de stockage pour vos sauvegardes Intégrez la communauté et prenez part aux débats Partagez des articles premium à vos contacts Abonnez-vous koocotte Premium Il y a 19 minutes Voir les réponses Message 1 Aller au commentaire enfant Signaler Bloquer cet utilisateur D'après les logs de ma machine, je constate 11 minutes de coupure, et je trouve que ça a été plutôt bien géré.Ce qui serait mieux, c'est qu'ils coupent proprement les VM avec un shutdown. Les machines viennent avec "QEMU Guest Agent" installé et lancé qui devrait permette de faire cela.
Dans mes logs, je constate que la machine n'a éteints aucun service, j'ai des logs normaux et ensuite directement les traces d'un nouveau boot. Heureusement, il n'y a pas eu de conséquence chez moi, mais manifestement ça a été la cause de soucis d'après ce RETEX. earendil_fr Premium Modifié à l'instant En réponse à Message 1.1 Historique Signaler Bloquer cet utilisateur Il me semble que certaines personnes coupent les agents de virtualisation sur les machines car ça ouvre un peu trop les accès depuis l'hyperviseur vers la VM hôte... carambas Premium Il y a 19 minutes Message 2 Signaler Bloquer cet utilisateur Je viens de comprendre pourquoi mon VPS avait redémarré tout seul le 9 juillet à 0h02. J'avais été surpris le lendemain car c'était vraiment inhabituel.
Signaler un commentaire Voulez-vous vraiment signaler ce commentaire ? Non Oui