Copy fail, alias CVE-2026-31431, est une faille du noyau Linux qui permet à un simple utilisateur local de devenir root en quelques secondes. Le problème vit dans l’interface algif_aead, le module qui expose les algorithmes de chiffrement du noyau aux programmes en espace utilisateur. Une preuve de concept publique circule déjà et les distributions patchent en urgence depuis fin avril 2026. La suite explique le mécanisme, les systèmes exposés et la marche à suivre pour se protéger.
Copy fail, une optimisation de 2017 qui se retourne contre le noyau
Le bug remonte à 2017, année où un commit a fait basculer les opérations AEAD (chiffrement authentifié) vers un traitement in-place, plus rapide mais moins prudent. Le chercheur Brian Pak, de l’équipe Xint Code, a documenté la faille le 29 avril 2026 et lui a donné son nom : Copy fail. Le score CVSS atteint 7,8, une note élevée pour une faille locale sans interaction utilisateur requise. Neuf ans séparent l’introduction du bug de sa découverte publique, un délai qui rappelle Dirty Pipe, une autre faille du noyau restée cachée plusieurs années avant son exploitation.
Un octet écrit au mauvais endroit, un binaire piraté en mémoire
Le mécanisme tient en une phrase : l’algorithme authencesn(hmac(sha256),cbc(aes)) écrit quatre octets de trop, hors de la zone de sortie prévue. Ces octets atterrissent dans des pages du cache mémoire du système (le page cache), là où sont stockées temporairement les données de fichiers lus récemment, y compris des binaires setuid comme /usr/bin/su ou des fichiers sensibles comme /etc/passwd. Un attaquant local ouvre un socket AF_ALG, y fait transiter le fichier ciblé via splice(), puis répète l’opération à différents offsets pour injecter un petit code malveillant dans la version en mémoire du binaire. Il ne reste plus qu’à exécuter ce binaire pour obtenir un shell root.
Copy fail réduit une décennie de code à quatre appels système et un octet bien placé, sans race condition ni fenêtre de timing à négocier.
La preuve de concept publiée par les chercheurs tient en moins de 800 octets de Python et fonctionne sans modification sur Ubuntu, Amazon Linux, RHEL et SUSE.
CVE-2026-31431, quels systèmes Linux sont concernés ?
Toutes les versions du noyau comprises entre 4.14 et 7.0-rc restent vulnérables, ainsi que les branches 6.18.x antérieures à 6.18.22 et 6.19.x antérieures à 6.19.12. Le correctif officiel arrive avec les noyaux 7.0, 6.19.12 et 6.18.22, via le commit mainline a664bf3d603d qui annule purement l’optimisation de 2017. Les branches LTS plus anciennes (6.12, 6.6, 5.15, 5.10) héritent aussi du problème par rétroportage et reçoivent leurs propres correctifs.
Le risque grimpe nettement sur certains environnements :
- serveurs mutualisés où plusieurs clients partagent le même noyau, une configuration qu’on retrouve souvent sur ce qu’est un serveur VPS d’entrée de gamme
- fermes de build et runners CI/CD accessibles à des jobs non fiables, un terrain qui touche de près les bases du métier DevOps
- conteneurs et hôtes Kubernetes où un pod compromis touche encore au noyau hôte
- postes de travail partagés entre plusieurs comptes utilisateurs
Sur une machine mono-utilisateur sans accès tiers, l’exposition réelle reste faible malgré la gravité technique du bug.
Patcher son noyau selon sa distribution
Le réflexe universel consiste à vérifier la version active du noyau avec uname -r, puis à comparer le résultat au tableau ci-dessous.
| Distribution | Version corrigée | Commande de mise à jour |
|---|---|---|
| Ubuntu 24.04 / 22.04 | 6.8.0-117.117 / 5.15.0-179.189 | apt update && apt upgrade |
| Debian 12 / 13 | 6.1.170-3 / 6.12.86-1 | apt update && apt upgrade |
| AlmaLinux 8 / 9 / 10 | 4.18.0-553.121.1 / 5.14.0-611.49.2 / 6.12.0-124.52.2 | dnf clean metadata && dnf upgrade |
| SUSE (séries LTS 6.12, 6.6, 5.15, 5.10) | 6.12.85 / 6.6.137 / 5.15.204 / 5.10.254 | zypper update kernel-default |
| Amazon Linux 2023 | correctif publié, version exacte à vérifier via l’avis ALAS | yum update kernel |
Un redémarrage reste indispensable après l’installation : le noyau corrigé ne prend effet qu’au prochain démarrage de la machine.
Contourner en attendant, sans paniquer
Sur une machine qu’il n’est pas encore possible de redémarrer, **désactiver l’interface algif_aead** coupe court à l’exploitation. La méthode passe par un profil seccomp qui bloque la création de sockets AF_ALG ou par la désactivation de l’option CONFIG_CRYPTO_USER_API_AEAD à la compilation du noyau. Cette interface sert surtout au chiffrement de disque et à quelques outils de crypto en espace utilisateur, rarement à des applications grand public.
La détection complète l’arsenal. L’équipe Sysdig a publié une règle Falco open source qui repère la création d’un socket AF_ALG de type SEQPACKET par un processus inattendu, premier signal d’une tentative d’exploitation. Le CERT Santé français classe déjà la faille comme activement exploitée, un signal qui justifie une priorité haute même sur des serveurs jugés secondaires.
Copy fail reste une escalade locale : elle ne s’exploite pas à distance sans un accès préalable au système, par exemple via une application web vulnérable. Cette limite n’enlève rien à sa dangerosité une fois qu’un pied est posé sur la machine, le passage à root prend alors quelques secondes.
