Copy Fail (CVE-2026-31431) : analyse rapide de cette vulnérabilité du noyau Linux
Vulnérabilité CVE-2026-31431 (Copy Fail) du noyau Linux (escalade de privilèges vers root). Analyse et recommandations de mitigation.
Publié le par Emmanuel LASTRA Mis à jour le 4 min de lecture
La vulnérabilité CVE-2026-31431 (score CVSS 7.8), surnommée “Copy Fail” et marketée comme une start-up 4.0 (avec site web et logo), touche le Linux kernel (Noyau linux) et permet à un utilisateur déjà présent sur une machine d’obtenir les droits root. Elle a été découverte grâce à l’outil d’analyse assistée par IA Xint de Theori, en environ une heure de scan sur le sous-système cryptographique du noyau et divulguée publiquement le 29 avril 2026, avec fourniture d’un PoC (Proof of Concept) exploitant la faille.
De quoi s’agit-il ?
Il s’agit d’une erreur logique dans le module authencesn, née d’une optimisation de performance introduite en 2017 qui permet au noyau de traiter des données “en place”, c’est-à-dire d’utiliser la même zone mémoire pour l’entrée et la sortie d’une opération cryptographique. En combinant l’interface AF_ALG et l’appel système splice(), un attaquant peut lier des pages du cache de fichiers à un socket cryptographique et détourner une écriture interne du noyau pour placer 4 octets contrôlés directement en mémoire vive, dans le cache d’un binaire qu’il ne possède pas.
L’impact est sévère pour plusieurs raisons. L’escalade de privilèges vers root est totalement déterministe : contrairement à Dirty Cow ou Dirty Pipe, l’attaque ne repose sur aucune race condition, elle fonctionne à chaque tentative. Un script Python de 732 octets suffit, sans dépendance externe, sur la quasi-totalité des distributions modernes (Ubuntu, RHEL, SUSE, Amazon Linux). La corruption n’affecte que la mémoire et non le fichier sur disque, ce qui la rend invisible pour les outils de vérification d’intégrité classiques comme AIDE ou Tripwire. Enfin, dans les environnements Kubernetes, le cache de pages étant partagé avec l’hôte, la faille peut servir de primitive d’évasion de conteneur et compromettre l’intégralité d’un nœud depuis un pod compromis.
Chronologie et problématique de la divulgation publique
| Date | Étape |
|---|---|
| 23 mars 2026 | Signalement à l’équipe sécurité du Linux kernel |
| 24 mars 2026 | Accusé de réception officiel |
| 25 mars 2026 | Propositions de patch + revue technique |
| 1 avril 2026 | Patch intégré dans le mainline Linux kernel |
| 22 avril 2026 | Attribution du CVE-2026-31431 |
| 29 avril 2026 | Divulgation publique (copy.fail + publications associées) |
La divulgation publique, intervenue le 29 avril 2026, s’est donc produite après la correction upstream, mais avant que l’ensemble des distributions Linux aient pu intégrer, recompiler et déployer les versions corrigées dans leurs dépôts stables. Ce décalage met en évidence une caractéristique structurelle de l’écosystème Linux : le kernel peut être sécurisé en amont, tandis que les systèmes en production restent temporairement exposés le temps que les chaînes de packaging et de validation des distributions rattrapent le cycle upstream. Ce décalage combiné à une stratégie de divulgation publique “en fanfare” (site dédié, PoC public, etc.) peut accélérer l’exploitation de la vulnérabilité par des attaquants malveillants sur des distributions non patchées.
Versions concernées
Le bug est présent dans tous les noyaux issus du commit introduit en août 2017, à partir de Linux 4.14. Les versions corrigées dans les branches stables sont les suivantes :
| Branche | Version corrigée |
|---|---|
| 5.10.x | 5.10.254+ |
| 5.15.x | 5.15.204+ |
| 6.1.x | 6.1.170+ |
| 6.6.x | 6.6.137+ |
| 6.12.x | 6.12.85+ |
| 6.18.x | 6.18.22+ |
| 6.19.x | 6.19.12+ |
| 7.0+ | non affecté |
Que faire ?
Même si le noyau est patché cela ne garantit pas que votre distribution a publié les mises à jour de sécurité correspondantes.
Vérifier votre version du noyau et installer les mises à jour de sécurité fournies par votre distribution Linux dès qu’elles sont disponibles, puis redémarrer la machine pour charger le noyau corrigé.
Vous pouvez facilement vérifier la version de votre noyau avec la commande uname -r et la comparer aux versions corrigées listées ci-dessus.
Chaque distribution (Debian, Ubuntu, RHEL, etc.) publie ses propres paquets corrigés : tant qu’ils ne sont pas installés et actifs après redémarrage, la faille reste exploitable.
Si votre distribution n’a pas encore publié de paquet corrigé, désactivez le module vulnérable. Pour la grande majorité des charges de travail, algif_aead n’est pas nécessaire :
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
La mesure est détaillée, avec les vérification préalables, dans la section “Mitigation” du site copy.fail.
Mise à jour du 7 mai 2026 :
- Canonical a rapidement déployé une mitigation pour les systèmes Ubuntu affectés par la vulnérabilité Copy Fail (CVE-2026-31431). Celle-ci ne corrige pas encore directement la faille dans le noyau Linux, mais désactive le module
algif_aeadvia une mise à jour du paquetkmod, empêchant ainsi l’exploitation du composant vulnérable. Un correctif complet au niveau du kernel est toujours en cours de déploiement dans les paquets linux-image. Cette approche permet de réduire immédiatement la surface d’attaque, au prix éventuel d’une perte des optimisations matérielles liées au chiffrement. - La distribution AlmaLinux a réagi rapidement à la vulnérabilité Copy Fail (CVE-2026-31431) en publiant des kernels corrigés pour l’ensemble des versions supportées. Contrairement à une simple mitigation (Ubuntu), AlmaLinux a intégré directement le correctif upstream dans ses builds kernel, déjà en cours de déploiement dans les dépôts de production. Une simple mise à jour suivie d’un redémarrage suffit désormais pour appliquer le correctif. Cette approche vise à éliminer la vulnérabilité à la source, en retirant la logique fautive introduite dans une optimisation du sous-système crypto du kernel Linux.