Comment KernelCare a corrigé Januscape avant que OVHcloud ne procède à ses redémarrages massifs

Principaux enseignements :

• OVHcloud a corrigé Januscape en redémarrant des dizaines de milliers de serveurs sur une période de 11 jours, ce qui a entraîné des interruptions de service réelles, des pannes matérielles et la mise en place d'une cellule de crise mondiale.
• KernelCare a fourni les deux correctifs Januscape requis sous forme de correctifs sans redémarrage, également appelés « correctifs en direct », dont la diffusion sur le flux principal a débuté le 7 juillet, avant la première vague de redémarrages d'OVH prévue le 8 juillet.
• Les correctifs nécessitant un redémarrage laissent chaque hôte vulnérable jusqu'au moment de son redémarrage, tandis que les correctifs sans redémarrage mettent fin à la fenêtre d'exposition dès l'application du correctif.

OVHcloud a publié l'une des analyses rétrospectives les plus franches sur les infrastructures que le secteur de l'hébergement ait connues depuis des années.

Pour remédier à la faille Januscape, référencée sous le numéro CVE-2026-53359, l'entreprise a appliqué des correctifs et redémarré des dizaines de milliers d'hôtes KVM hébergeant environ un million de machines virtuelles. L'opération s'est étendue à tous les continents, a nécessité une intervention d'urgence 24 heures sur 24, 7 jours sur 7, et a duré 11 jours.

Le site The Register a couvert cette campagne. L'analyse rétrospective complète d'OVHcloud est une lecture incontournable pour toute personne en charge d'un parc de virtualisation de grande envergure.

Du point de vue opérationnel, c'est vraiment impressionnant. Les équipes d'OVHcloud ont réagi rapidement, ont su gérer les défaillances malgré la pression et ont rendu compte des résultats avec une transparence hors du commun.

Du point de vue des infrastructures, cela soulève une question plus épineuse.

Pourquoi l'application d'un correctif du noyau a-t-elle nécessité une opération de redémarrage à grande échelle ?

Voici la différence. Pour les plateformes prises en charge par KernelCare, le correctif Januscape sans redémarrage était déjà disponible dans le flux de correctifs principal avant même qu’OVH ne redémarre son premier serveur. Les parcs abonnés l’ont intégré dans le cadre d’un cycle de mise à jour normal. Pas de redémarrage. Pas d’interruption. Pas de campagne.

Januscape en deux phrases

Januscape est une vulnérabilité de type « use-after-free » présente dans le code de gestion de la mémoire fantôme x86 de KVM. Un attaquant disposant d'un accès root au sein d'une machine virtuelle invitée pourrait l'exploiter pour provoquer le plantage de l'hôte et, éventuellement, exécuter du code avec des privilèges au niveau de l'hôte.

Cette faille affecte les systèmes Intel et AMD et était présente dans le noyau Linux depuis environ 16 ans. Sa correction nécessite deux correctifs en amont associés aux identifiants CVE-2026-53359 et CVE-2026-46113.

Notre analyse technique Januscape passe en revue en détail la vulnérabilité, la chaîne d'exploitation et les correctifs nécessaires.

Nous avons également organisé un live pour analyser en détail cette faille, si vous préférez écouter deux experts discuter de cette vulnérabilité (CVE) plutôt que de vous plonger encore davantage dans la documentation à ce sujet.

L'article que vous êtes en train de lire porte sur le projet de loi de finances.

Quels correctifs nécessitent un redémarrage ?

Toutes les informations ci-dessous sont tirées du rapport d'analyse rétrospective d'OVH et de l'article du Register. Il ne s'agit en aucun cas de spéculations.

OVHcloud a d'abord testé sa procédure de déploiement à Sydney. Cette région présentait un encombrement relativement faible, une demande nocturne réduite et une couverture pendant les heures de travail assurée par les équipes européennes. Une fois le guide d'intervention validé, les redémarrages ont été étendus à l'échelle mondiale grâce à un fonctionnement en continu (« follow-the-sun »).

Ce processus allait bien au-delà de la simple installation d’un paquet du noyau et du redémarrage des machines. Les vagues de redémarrage étaient régies par des seuils d’arrêt. OVHcloud suspendait une vague si 15 hôtes étaient hors service simultanément dans une région à forte densité ou si cinq l’étaient ailleurs.

Pour les projets clients répartis sur plusieurs hôtes, les orchestrateurs ont calculé un graphe de colocalisation. L'objectif était d'éviter que deux hôtes hébergeant le même projet ne redémarrent au cours de la même fenêtre.

Les équipes ont également recensé les dépendances internes entre les services avant chaque déploiement régional. Certaines machines virtuelles critiques ont dû être migrées en direct au préalable afin que les bases de données, les API, les systèmes de surveillance et les autres services opérationnels restent disponibles pendant les redémarrages.

Les clients dont toutes les instances occupaient un seul hôte ont subi une interruption. Une fenêtre de maintenance leur a été communiquée, mais l'urgence de l'intervention de sécurité a rendu impossible toute option de refus.

C'est alors que les problèmes matériels sont apparus. La première nuit, environ 20 à 30 serveurs sur 6 000 n'ont pas redémarré d'eux-mêmes : modules de mémoire défectueux, problèmes de BIOS, cartes réseau hors service.

Aux États-Unis, certaines machines nécessitaient de retirer la batterie CMOS et de les mettre hors tension avant de pouvoir démarrer. Des techniciens de centre de données ont été déployés sur chaque site pendant toute la durée de l'opération, afin de remplacer des pièces et d'effectuer des interventions manuelles sur les baies, tâches qu'aucun orchestrateur ne peut automatiser.

Les logiciels ont eux aussi posé des problèmes. Les machines virtuelles ne parvenaient pas à redémarrer après le redémarrage de l’hôte, jusqu’à ce qu’un conflit entre libvirt et les machines invitées soit identifié et contourné. Des arrêts forcés ont corrompu les données sur les machines virtuelles de trois clusters. Les API OpenStack de Paris se sont retrouvées dans une impasse, générant deux heures de codes d’erreur HTTP 503, ce qui a retardé une vague. Sur le site canadien, le trafic a atteint 10 fois le pic habituel, submergeant le service d’assistance.

Il faut rendre à César ce qui appartient à César : la cellule de crise d'OVH a très bien géré la situation, et rendre publics ces dysfonctionnements demande plus de courage que n'en ont la plupart des fournisseurs.

Ce n'est pas l'exécution qui posait problème. C'est le modèle de correctifs qui l'imposait.

Ce qu'ont fait à la place les systèmes protégés par KernelCare

Les parcs informatiques utilisant KernelCare ont géré cette même vulnérabilité sans recourir à aucun des mécanismes opérationnels décrits ci-dessus. Pas de vagues de redémarrages, pas de fenêtres de maintenance, pas de déploiement de techniciens.

L'objectif actuel de TuxCare concernant les escalades de privilèges locaux et les vulnérabilités « zero-day » est de fournir des correctifs en temps réel dans les 48 heures suivant leur divulgation publique. Dans le cas présent, ce délai a été raccourci : l'embargo a été levé le 6 juillet, et KernelCare a commencé à déployer les deux correctifs nécessaires simultanément via son processus habituel de correction sans redémarrage, parfois appelé « correctif en temps réel », dès le 7 juillet (soit environ 24 heures plus tard).

Comme l'indique notre analyse technique Januscape, la couverture généralement disponible au 7 juillet comprenait :

• La gamme Enterprise Linux 10
• Ubuntu 22.04, y compris les versions cloud
• Debian 13
• Systèmes Ubuntu Focal utilisant le noyau Jammy optimisé pour le matériel
• Proxmox VE 7 et 8

D'autres familles de noyaux ont ensuite franchi les étapes de développement, de test et de déploiement progressif.

OVHcloud a lancé ses premières vagues de redémarrage à Sydney le lendemain, le 8 juillet.

Ainsi, alors qu’une partie des opérateurs était encore en train de planifier des temps d’arrêt, les flottes mises à jour étaient déjà protégées – avec la réserve habituelle que cela ne prouve pas que les correctifs du 7 juillet auraient été applicables aux noyaux Debian de production d’OVHcloud. OVHcloud n’a pas divulgué publiquement suffisamment d’informations sur les versions pour permettre de l’établir.

Cela illustre bien l'alternative opérationnelle qui s'offre aux hébergeurs utilisant des noyaux pris en charge.

Une fois que le correctif sans redémarrage applicable était disponible sur le système, le code vulnérable pouvait être remplacé sans redémarrer l'hôte. Il n'y avait donc pas de fenêtre de redémarrage à planifier, pas besoin d'organiser les charges de travail des clients en fonction d'un redémarrage, ni d'envoyer d'avis aux clients concernant ce redémarrage.

Il n'y avait pas non plus de problèmes matériels latents susceptibles de se manifester lors d'un redémarrage d'urgence.

Les administrateurs pouvaient vérifier directement la couverture :

kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'

La différence ne réside pas dans le fait qu'un groupe ait pris Januscape au sérieux et l'autre non. Les deux l'ont fait.

L'approche d'OVH a transformé cette correction en un événement majeur au niveau de l'infrastructure, alors que l'application de correctifs sans redémarrage via KernelCare en aurait fait un simple déploiement de correctifs de routine.

La « fenêtre d'exposition » : un coût caché

L'installation d'un paquet de noyau corrigé ne protège pas le noyau actuellement en cours d'exécution. La vulnérabilité reste active jusqu'à ce que la machine redémarre avec la version mise à jour.

Cela crée une fenêtre d'exposition pour tous les hôtes qui attendent encore leur tour.

OVHcloud a clairement reconnu ce problème. Traiter chaque client individuellement aurait prolongé la durée de la campagne et laissé une grande partie du parc vulnérable pendant des semaines. L'entreprise a également limité ses communications publiques pendant le déploiement, craignant que des clients ne testent la faille de sécurité rendue publique sur son infrastructure de production.

Avec l'application de correctifs sans redémarrage, la fenêtre se ferme une fois que le correctif concerné a été appliqué avec succès. La mise à jour classique du noyau et le redémarrage peuvent alors avoir lieu ultérieurement, lors d'un cycle de maintenance planifié, plutôt qu'en pleine situation d'urgence liée à la sécurité.

Les correctifs sans redémarrage sont-ils trop instables ?

OVHcloud a étudié la possibilité d'appliquer des correctifs sans interruption de service et a rejeté cette option. Son analyse rétrospective fait valoir que la modification d'un noyau en cours d'exécution peut réduire le niveau de sécurisation et entraîner une instabilité à l'échelle de l'ensemble du parc.

Cette préoccupation mérite une réponse directe. Examinons-la sous trois angles différents :

Tout d'abord, voyons comment ces correctifs sont effectivement déployés. Chaque correctif KernelCare est compilé et testé sur la version spécifique du noyau à laquelle il est destiné, puis passe par une validation interne et une série de tests avant d'être intégré au flux de production. Les parcs informatiques qui souhaitent un niveau de contrôle supplémentaire utilisent KernelCare ePortal et définissent leurs propres étapes de validation et politiques de déploiement. Il s'agit d'un pipeline de déploiement éprouvé.

Deuxièmement, ce bug en particulier. Le correctif « Januscape » est un exemple parfait de correctif pouvant être appliqué sans redémarrage : il s'agit d'une correction localisée dans la chaîne de gestion des erreurs de la MMU de KVM, sans état persistant à migrer ni structures de données à transformer. Si l'on devait concevoir un CVE pour illustrer l'intérêt des correctifs sans redémarrage, ce serait exactement celui-ci.

Troisièmement, et c’est là-dessus qu’il faut s’attarder : le rapport d’analyse rétrospective d’OVH met en évidence l’instabilité du processus de redémarrage. Des dizaines de serveurs qui ne se sont jamais remis en marche. Des disques endommagés à la suite d’arrêts forcés. Un blocage de l’API régionale. Des machines virtuelles bloquées hors ligne en raison d’un conflit de services. Le choix n’a jamais porté sur un correctif sans redémarrage risqué ou un redémarrage sans risque. Il s’agissait de choisir entre deux méthodes présentant des profils de risque différents, et à l’échelle d’un parc de serveurs, les risques liés à la procédure de redémarrage sont importants, concrets et documentés. La stabilité est une propriété de l’ensemble du processus de correction, et non du mécanisme de correctif pris isolément.

Si votre parc informatique peut être entièrement redémarré en moins de 24 heures sans impact sur les clients, la donne peut véritablement changer pour vous. Si une vulnérabilité CVE du noyau implique une campagne de plusieurs semaines, la mise en place d’une cellule de crise et la présence de techniciens dans chaque centre de données, c’est le modèle qui pose problème, et non votre équipe.

Campagne de redémarrage ou application de correctifs sans redémarrage

Cela se reproduira probablement

Januscape n'était pas un événement isolé.

CopyFail, DirtyFrag, GhostLock et d'autres vulnérabilités graves du noyau ont toutes contraint les équipes chargées des infrastructures à prendre des décisions urgentes concernant l'exposition aux risques, les temps d'arrêt et les mesures correctives.

Le responsable de la sécurité des systèmes d'information (RSSI) d'OVHcloud a reconnu que de nouvelles vulnérabilités du noyau pourraient nécessiter de répéter cette procédure d'urgence. La priorité immédiate de l'entreprise est de rendre cette procédure plus sûre et plus prévisible la prochaine fois.

D'autres hébergeurs proposent une autre option.

Elles permettent de réduire le risque qu'une vulnérabilité du noyau ne se traduise par un incident affectant l'infrastructure accessible aux clients.

OVHcloud a démontré qu'il était possible de mener à bien une campagne de redémarrage à grande échelle même sous pression. KernelCare a quant à lui démontré que, pour les systèmes pris en charge, cette même vulnérabilité pouvait être corrigée dans un noyau en cours d'exécution sans avoir à lancer cette campagne.

La leçon à retenir de l'affaire Januscape n'est pas que les hébergeurs ont besoin d'un meilleur guide de procédure de redémarrage.

Le but est qu'ils n'aient pas à en activer une à chaque fois qu'une faille critique du noyau apparaît.

Bénéficiez de mises à jour sans redémarrage avec KernelCare →