Plusieurs vulnérabilités récentes du noyau Linux ont nécessité une réponse rapide de la part des opérateurs d'infrastructure. Parmi elles, Copy Fail et Dirty Frag ont attiré l'attention car elles concernent des scénarios d'élévation locale de privilèges.

Copy Fail est suivie sous la CVE-2026-31431.

Dirty Frag regroupe deux vulnérabilités distinctes, la CVE-2026-43284 et la CVE-2026-43500, liées à des composants du noyau Linux.

Chez Clever Cloud, nous avons traité ces vulnérabilités comme des sujets d'infrastructure critiques.

Notre objectif était double : réduire rapidement la fenêtre d'exposition, puis améliorer durablement notre processus de sélection et de déploiement des kernels.

Cet article revient sur notre approche, les décisions prises et les changements apportés à notre chaîne d'exploitation.

Pourquoi ces vulnérabilités demandaient une réaction rapide

Copy Fail et Dirty Frag appartiennent à la famille des vulnérabilités d'élévation locale de privilèges. Dans ce type de scénario, un attaquant doit déjà pouvoir exécuter du code localement, mais peut ensuite tenter d'obtenir des privilèges plus élevés sur la machine concernée.

Dirty Frag repose sur deux failles du noyau Linux.

Elles affectent notamment des modules liés à ESP, utilisé par IPsec, et à RxRPC. Dans une plateforme cloud, ce type de vulnérabilité impose une analyse rapide. Le risque ne se limite pas à la machine isolée. Il faut aussi évaluer les scénarios liés aux environnements mutualisés, aux workloads containerisés et aux mécanismes d'isolation.

Ce que nous avons vérifié

Nous avons analysé l'impact potentiel de ces vulnérabilités sur nos environnements.

Cette étape ne consiste pas seulement à lire les avis de sécurité.

Elle consiste aussi à vérifier si un scénario théorique peut devenir pertinent dans notre contexte d'exploitation.

Dans le cas de CopyFail, la faille venait sous embargo avec son correctif. Nous avons publié une nouvelle image système avec le correctif appliqué dans les jours qui ont suivi.

Les applications de nos clients ont été redéployées dans la foulée.

Dans le cas de Dirty Frag, nos analyses internes ont confirmé que ces vulnérabilités devaient être traitées sérieusement. En effet, les modules ESP sont activés dans nos noyaux pour répondre à certains besoins client spécifiques.

Heureusement, les modules liés à RxRPC ne sont pas présents chez nous car inutile dans notre usage. Nous ne détaillons pas ici les étapes techniques de l'exploitation, car l'objectif de cet article est d'informer nos clients, pas de publier une procédure reproductible.

Cette validation a confirmé la décision opérationnelle : traiter le sujet immédiatement, réduire la surface exposée, puis forcer les redéploiements nécessaires.

Notre réponse opérationnelle

Déployer des mesures immédiates

Nous avons d'abord appliqué des mesures rapides sur les kernels concernés. Dans le cas de Dirty Frag, les mesures publiques recommandées portent notamment sur les composants kernel concernés par ESP et RxRPC.

Côté Clever Cloud, l'objectif était clair : réduire les surfaces exposées identifiées et réduire la fenêtre d'exposition avant d'attendre un cycle classique de maintenance

Redéployer les workloads concernés

Une mise à jour kernel n'est utile que si les systèmes concernés redémarrent effectivement sur un environnement corrigé. Nous avons donc lancé un redéploiement progressif des applications, puis traité les cas qui bloquaient ce redéploiement.

Cette phase est importante. Dans une plateforme managée, la correction ne se limite pas à produire une image ou à compiler un kernel. Il faut aussi s'assurer que la chaîne d'exécution utilise réellement la version attendue.

Améliorer le processus au passage

Nous avons aussi profité de cette séquence pour remplacer un mécanisme temporaire par une intégration plus propre dans notre chaîne d'orchestration.

Concrètement, le choix du kernel est désormais transmis plus explicitement dans notre chaîne interne, jusqu'à Supernova, notre agent d'hyperviseur. Cette évolution remplace le contournement plus rigide mis en place dans l'urgence.

C'est le point central de cette intervention : corriger vite, puis rendre la correction plus fiable pour les prochaines opérations.

Ce que cela change pour les clients de Clever Cloud

Pour les clients, l'effet attendu est simple : réduire l'exposition sans action manuelle de leur part lorsque la plateforme peut prendre en charge le redéploiement.

Clever Cloud exploite une architecture qui repose notamment sur l'isolation par virtualisation. Cette approche est documentée dans nos pages sécurité et dans nos contenus techniques sur l'exécution de conteneurs dans des machines virtuelles.

Elle ne supprime pas tous les risques, mais elle limite certains scénarios de mouvement latéral par rapport à des modèles où plusieurs workloads partagent directement le même environnement d'exécution.

Nous évitons toutefois de présenter cette isolation comme une garantie absolue. Une vulnérabilité kernel doit toujours être traitée sérieusement. C'est pourquoi nous avons combiné mitigation, redéploiement et amélioration de notre chaîne d'exploitation.

Ce que nous retenons

Cette séquence confirme trois principes.

D'abord, une vulnérabilité kernel doit être analysée dans son contexte réel d'exploitation. Une alerte publique ne suffit pas.

Il faut comprendre si les conditions nécessaires à l'exploitation peuvent exister sur la plateforme.

Ensuite, la vitesse de réaction compte. Les vulnérabilités Copy Fail et Dirty Frag ont été divulguées publiquement à quelques jours d'intervalle, avec des analyses publiées par plusieurs acteurs de l'écosystème Linux et cloud.

Enfin, une réponse sécurité utile ne doit pas seulement corriger le problème du moment. Elle doit aussi améliorer le système qui permettra de répondre au prochain incident.

C'est ce que nous avons fait ici : traiter les vulnérabilités, réduire la fenêtre d'exposition et renforcer notre processus de gestion des kernels.

FAQ

Qu'est-ce qu'une vulnérabilité kernel locale ?

Une vulnérabilité kernel locale est une faille qui nécessite déjà une capacité d'exécution sur la machine concernée. Elle peut ensuite permettre d'obtenir des privilèges plus élevés, par exemple root, si le noyau est vulnérable.

Pourquoi ces failles concernent-elles les plateformes cloud ?

Les plateformes cloud exécutent de nombreux workloads avec des mécanismes d'isolation. Une faille kernel peut devenir critique si elle permet de franchir certaines barrières entre processus, conteneurs ou environnements d'exécution.

Dirty Frag et Copy Fail sont-elles la même vulnérabilité ?

Non. Copy Fail est suivie sous la CVE-2026-31431. Dirty Frag regroupe la CVE-2026-43284 et la CVE-2026-43500. Ces vulnérabilités sont proches par leur impact, mais elles sont distinctes.

Quelle action est demandée aux clients Clever Cloud ?

Aucune action générale n'est demandée aux clients pour les environnements pris en charge par la plateforme. L'automatisation apportée par Clever Cloud a permis de tout mettre à jour sans action nécessaire. Les cas spécifiques font l'objet d'un suivi dédié.