Suite à la faille KVM, OVHcloud fait le bilan de sa migration monstre
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.
Le 6 juillet, une faille critique nommée Januscape (référence CVE-2026-53359) a été découverte dans le moteur de virtualisation KVM (Kernel-based Virtual Machine), un outil essentiel qui permet de faire fonctionner plusieurs machines virtuelles sur un même serveur physique. Cette faille affecte spécifiquement l’architecture x86 et réside dans le shadow paging, un mécanisme gérant la mémoire des machines virtuelles. Concrètement, elle permet à un attaquant d’exploiter une référence obsolète vers une page mémoire déjà libérée, pouvant provoquer un plantage de l’hyperviseur (le logiciel qui gère les machines virtuelles) ou, dans le pire des cas, une élévation de privilèges, c’est-à-dire donner un accès administrateur à un utilisateur non autorisé. OVHcloud, qui repose sur KVM pour la majorité de ses instances, a confirmé que cette faille était exploitable en seulement deux minutes sur un serveur non corrigé.
Dès le lendemain de la découverte de la faille, OVHcloud a constitué une cellule de crise pour évaluer cinq solutions possibles de mise à jour de ses infrastructures. Parmi elles figuraient l’attente des noyaux Linux officiels, l’utilisation d’un live patch (correctif appliqué sans redémarrage), la désactivation de la virtualisation imbriquée (technique permettant de faire tourner des machines virtuelles dans d’autres machines virtuelles), ou encore une migration live (déplacement des machines virtuelles vers des serveurs corrigés sans interruption). OVHcloud a finalement opté pour une approche radicale : intégrer elle-même le correctif dans ses noyaux personnalisés, puis redémarrer l’intégralité de ses serveurs hôtes. Cette solution, décrite comme un patching unilatéral à impact contrôlé, visait à protéger le plus grand nombre de clients, malgré un impact temporaire sur une minorité. Le choix a été validé par le comité exécutif dès le 7 juillet, et les tests ont confirmé l’efficacité du correctif en quelques heures.
Pour limiter les risques, OVHcloud a déployé sa mise à jour selon une stratégie géographique et temporelle précise. Les opérations ont commencé le 8 juillet dans la région Sydney, où le nombre de serveurs est limité, puis ont suivi les régions européennes (RBX, GRA6, WAW, etc.) en fonction des fuseaux horaires. Chaque vague de redémarrages était encadrée par des seuils d’arrêt automatique : 15 hôtes en panne simultanée pour les régions denses, 5 pour les autres, avec un arrêt systématique à 6h00 locales ou sur demande. OVHcloud a également veillé à ne pas redémarrer deux serveurs hébergeant des machines virtuelles d’un même projet simultanément, afin d’éviter des indisponibilités prolongées. Les régions à faible densité ont été traitées en premier, tandis que les zones à fort volume ont fait l’objet d’une orchestration plus fine, lot par lot.
Malgré les précautions, des problèmes sont survenus lors du déploiement. Certains machines virtuelles n’ont pas redémarré correctement après le reboot de leur serveur hôte, en raison d’un conflit entre libvirt-guests.service et Nova Compute. D’autres ont subi des corruptions de données, probablement causées par des redémarrages forcés en pleine écriture sur le disque. À Paris, une saturation des API Nova et Neutron a provoqué deux heures de panne HTTP 503. Sur le plan matériel, environ 20 à 30 serveurs sur 6 000 n’ont pas redémarré seuls, nécessitant parfois une intervention manuelle (remplacement de barrettes mémoire, réinitialisation du BIOS, etc.). Ces incidents ont été résolus en étendant la période d’attente avant un kill forcé et en déployant un script de redémarrage automatique pour les machines virtuelles restées éteintes.
OVHcloud a informé ses clients de manière progressive et ciblée, région par région, via des messages personnalisés. Pour éviter de saturer son support client, l’entreprise a d’abord évité l’envoi massif d’e-mails, notamment pour la région GRA6 qui compte près de 90 000 clients. Une bannière conditionnelle a été ajoutée dans le Manager (l’interface de gestion d’OVHcloud) le lendemain, suivie par la création d’une page de statut dédiée au Public Cloud. Malgré ces efforts, OVHcloud reconnaît que la communication pourrait être améliorée, notamment pour informer en amont les clients et accompagner ceux impactés. L’entreprise souligne que cette opération, bien que réussie dans son ensemble, a révélé des limites dans la gestion des incidents et la transparence, avec des retours clients comme des coupures de 11 minutes ou des redémarrages non planifiés.
Cette migration massive, qui s’est étalée sur 11 jours, a été une première pour OVHcloud, qui n’avait jamais dû gérer une situation critique d’une telle ampleur. L’entreprise estime que ce type de procédure d’urgence pourrait se reproduire fréquemment, en raison du rythme accéléré des publications de vulnérabilités noyau, notamment sous l’impulsion de l’*intelligence artificielle générative*. OVHcloud a identifié trois axes d’amélioration : mieux maîtriser l’impact des redémarrages sur les clients, améliorer l’information en amont, et renforcer l’accompagnement des clients impactés. L’entreprise conclut en reconnaissant que, malgré un *exploit* réalisé par ses équipes, elle devra faire mieux lors des prochaines opérations, en réduisant notamment les indisponibilités et en optimisant la communication.
