Copy Fail – CVE-2026-31431

• Un utilisateur local non privilégié peut chaîner authencesn, AF_ALG et splice() pour obtenir une écriture de 4 octets dans le page cache d’un fichier lisible, puis s’en servir pour élever ses privilèges jusqu’à root
• L’exploit fonctionne tel quel sur plusieurs distributions Linux avec un script Python de 732 octets unique, sans offset spécifique au noyau ni condition de course, et permet d’obtenir un root shell avec le même exploit
• Le périmètre d’impact couvre la plupart des grandes distributions Linux jusqu’à l’application du correctif, avec une exposition large de 2017 jusqu’au patch en raison de AF_ALG activé par défaut
• Dans les hôtes multi-tenant, les clusters Kubernetes / de conteneurs, les runners CI et les Cloud SaaS exécutant du code utilisateur, un simple compte ordinaire ou un pod peut mener au root de l’hôte, d’où la nécessité d’un correctif prioritaire
• La réponse prioritaire est un patch noyau incluant le commit mainline a664bf3d603d ; avant cela, il est important de désactiver algif_aead et de bloquer AF_ALG pour les charges de travail non fiables

---

Vue d’ensemble de la vulnérabilité

• Un simple défaut logique linéaire peut être chaîné via authencesn, AF_ALG et splice() jusqu’à une écriture de 4 octets dans le page cache, permettant une élévation locale de privilèges
• Sans offset propre à chaque noyau ni fenêtre de race, un seul script Python de 732 octets fonctionne de manière identique sur l’ensemble des distributions Linux publiées depuis 2017
• Le même binaire d’exploit permet d’obtenir un root shell sur plusieurs distributions sans modification
• Un simple compte local non privilégié suffit ; aucun accès réseau, aucune fonction de débogage noyau et aucune primitive préinstallée supplémentaire ne sont nécessaires

Périmètre d’impact

• La plupart des grandes distributions Linux utilisant un noyau non corrigé sont concernées
• Dans la configuration par défaut, AF_ALG de l’API cryptographique du noyau est activé sur pratiquement toutes les distributions grand public, ce qui crée une exposition immédiate de 2017 jusqu’au moment du patch
• Les distributions vérifiées directement sont Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3 et SUSE 16
• Debian, Arch, Fedora, Rocky, Alma, Oracle et les systèmes embarqués sont également affectés s’ils utilisent un noyau vulnérable

Environnements à corriger en priorité

• Sur les hôtes Linux multi-tenant, plusieurs utilisateurs partagent le même noyau, ce qui permet à un compte arbitraire de devenir directement root
• Dans les clusters Kubernetes / de conteneurs, le page cache est partagé à l’échelle de tout l’hôte ; un seul pod peut donc prendre le contrôle du nœud et franchir les frontières entre tenants
• Dans les runners CI et fermes de build, du code non fiable provenant d’une PR et exécuté avec les privilèges d’un utilisateur ordinaire peut devenir root sur le runner
• Dans les Cloud SaaS exécutant du code utilisateur, un conteneur ou un script envoyé par un tenant peut mener au root de l’hôte
• Les serveurs mono-tenant relèvent davantage d’une LPE interne, mais peuvent être combinés à une web RCE ou à des identifiants compromis
• Les ordinateurs portables et stations de travail mono-utilisateur sont moins urgents, mais une exécution locale de code peut tout de même mener directement à une élévation vers root

PoC publié et mode d’utilisation

• Le PoC est publié afin d’aider les équipes de défense à vérifier leurs systèmes et à confirmer les correctifs des éditeurs
• copy_fail_exp.py n’utilise que les bibliothèques standard Python 3.10+ os, socket et zlib
• La cible par défaut est /usr/bin/su ; il est possible de passer un autre binaire setuid via argv[1]
• Le binaire setuid dans le page cache est modifié ; le changement ne persiste pas après redémarrage, mais le root shell obtenu fonctionne réellement
• Issue tracker

Mesures d’atténuation

• La priorité est d’appliquer un patch noyau, en mettant à jour vers un noyau de distribution incluant le commit mainline a664bf3d603d
• Ce correctif annule l’optimisation in-place de algif_aead, introduite en 2017, afin d’empêcher qu’une page du page cache soit placée dans une scatterlist de destination inscriptible
• Avant le patch, la désactivation du module algif_aead est recommandée
  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead 2>/dev/null || true
• Dans les conteneurs, sandbox et environnements CI exécutant des charges non fiables, il faut bloquer la création de sockets AF_ALG via seccomp indépendamment de l’état du patch

Impact de la désactivation

• Sur la plupart des systèmes, l’impact mesurable est presque nul
• dm-crypt / LUKS, kTLS, IPsec/XFRM, TLS dans le noyau, les builds par défaut d’OpenSSL/GnuTLS/NSS, SSH et la crypto du kernel keyring ne sont pas affectés
  • Ils utilisent directement l’API cryptographique du noyau et ne passent pas par le chemin AF_ALG
• Si le moteur afalg est explicitement activé dans OpenSSL, certains chemins d’offload crypto embarqué ou les applications qui bindent directement des sockets aead/skcipher/hash peuvent être impactés
  • Vérification possible avec lsof | grep AF_ALG ou ss -xa
• Désactiver AF_ALG ne ralentit pas les composants qui ne l’appelaient pas déjà ; ceux qui l’utilisaient reviennent aux bibliothèques cryptographiques userspace classiques

Ce qui distingue cette LPE Linux des cas habituels

• Contrairement aux LPE Linux classiques, il n’y a pas de condition de course et aucun offset spécifique à chaque distribution n’est nécessaire
• La fiabilité est annoncée comme 100 % en une seule tentative, et la fenêtre affectée couvre une longue période, de 2017 à 2026, au lieu d’une plage étroite de versions de noyau
• Avec seulement 732 octets et la bibliothèque standard Python, il n’y a ni payload compilé ni dépendance supplémentaire
• Le chemin d’écriture contourne le VFS et la page corrompue n’est pas marquée dirty, donc rien n’est écrit sur disque
• Comme le page cache est partagé à l’échelle de l’hôte, il s’agit non seulement d’une LPE, mais aussi d’une primitive d’évasion de conteneur

Principe de fonctionnement et caractéristiques de détection

• Un utilisateur local non privilégié peut écrire 4 octets contrôlables dans le page cache d’un fichier lisible sur un système Linux, puis l’exploiter pour obtenir root
• La cible n’est pas le fichier réel sur disque mais le page cache en mémoire ; modifier la copie en cache de /usr/bin/su revient, du point de vue de execve, à modifier le binaire lui-même
• Comme il n’y a aucun changement sur disque, inotify ne se déclenche pas, et après redémarrage ou éviction du cache, le fichier original est rechargé
• Les outils de hachage classiques comme sha256sum, AIDE ou Tripwire lisent le page cache via read(), de sorte que tant que la corruption reste en cache, le hash peut différer de la valeur de référence
• Une fois le cache évincé ou après redémarrage, le hash redevient identique à l’original, et une image forensic du disque ne contient que le fichier non modifié
• En mode enforcing de l’IMA appraisal, si every-read measurement est activé, le binaire corrompu peut être détecté au moment de execve avant son exécution

Différences avec d’autres vulnérabilités

• Comme Dirty Pipe, cette vulnérabilité permet à un userspace non privilégié de corrompre le page cache et d’écrire dans un binaire setuid sans modification du disque pour obtenir root
• Le mécanisme est différent : Dirty Pipe exploitait les pipe buffer flags, tandis que Copy Fail exploite une AEAD scratch write qui franchit des frontières de scatterlist chaînées
• Dirty Pipe nécessitait un noyau 5.8+ avec un correctif spécifique, alors que Copy Fail couvre une fenêtre allant de 2017 à 2026
• Contrairement à Dirty Cow, il n’est pas nécessaire de gagner une race COW basée sur un TOCTOU, ni de multiplier les tentatives, ni de déstabiliser le système

Détails supplémentaires

• /usr/bin/su n’est pas obligatoire ; tout binaire setuid-root lisible par l’utilisateur peut convenir, notamment passwd, chsh, chfn, mount, sudo ou pkexec
• Ce n’est pas une vulnérabilité distante ; elle nécessite d’abord une exécution locale de code avec des privilèges utilisateur ordinaires
• Si une web RCE s’exécute sous un compte de service non privilégié, ou si elle est combinée à un accès SSH initial ou à une PR malveillante sur un runner CI, cela peut mener à root
• Le patch annule l’optimisation in-place de algif_aead et sépare à nouveau req->src et req->dst en scatterlists distinctes
• Les pages du page cache restent uniquement dans la source en lecture seule, et seules les buffers utilisateur demeurent comme cibles inscriptibles pour la crypto

Calendrier de divulgation et ressources complémentaires

• Signalé à l’équipe sécurité du noyau Linux le 2026-03-23
• Confirmation initiale le 2026-03-24
• Patch proposé et relu le 2026-03-25
• Patch intégré dans la branche mainline le 2026-04-01
• CVE-2026-31431 attribué le 2026-04-22
• Publication le 2026-04-29 sur https://copy.fail/
• Analyse technique du blog Xint
  • Contient la root cause, des diagrammes de scatterlist, la chronologie 2011→2015→2017 et une walkthrough de l’exploit
  • Une Part 2 sur l’évasion de conteneur Kubernetes doit être publiée ultérieurement

Informations liées à Xint Code

• La découverte a été faite de manière AI-assisted ; le point de départ était une recherche humaine selon laquelle splice() transmet des pages du page cache au sous-système crypto, et que l’origine des pages dans les scatterlists pouvait constituer une classe de bugs encore peu explorée
• Ensuite, Xint Code a étendu l’audit à l’ensemble du sous-système Linux crypto/ à l’échelle d’environ une heure, et l’élément le plus critique trouvé dans les résultats était Copy Fail
• Xint Code
  • Article détaillé du blog Xint
  • D’autres bugs à haut risque ont aussi été trouvés dans le même scan, et ils font encore l’objet d’une coordinated disclosure