La sécurité de Linux est confrontée à un nouveau défi suite à la découverte de la vulnérabilité CVE-2026-31431, baptisée « Copy Fail » par les chercheurs de Xint Code. Loin d'être une faille théorique, ce problème de conception permet à un utilisateur local non privilégié d'élever ses privilèges et d'obtenir un accès superutilisateur complet de manière prévisible et silencieuse.
Les chercheurs indiquent que cette faille a été exploitée avec succès dans des distributions de premier plan telles qu'Ubuntu, Amazon Linux, RHEL et SUSE, confirmant ainsi que tout système exécutant un noyau postérieur à la version 4.14 et prenant en charge les sockets AF_ALG est potentiellement vulnérable à cette attaque.
Opérations sur place et débordement du cache de pages
Concernant la vulnérabilité, il est indiqué qu'elle remonte à une optimisation introduite en 2017 au sein de l'API cryptographique du noyau (AF_ALG). Cette modification visait à éliminer la mise en mémoire tampon inutile en exécutant les opérations de chiffrement authentifiées (AEAD) directement dans le même espace mémoire, opérations dites « sur place ».
Le problème critique survient lors de la combinaison de cette optimisation avec la fonction `splice()`, qui transfère des données entre descripteurs de fichiers en transférant des références directes au cache de pages du noyau au lieu de copier physiquement les données. Lors d'une demande de déchiffrement, la structure de la mémoire était configurée de telle sorte que la mémoire tampon de destination, qui devrait être un espace temporaire pour l'utilisateur, se retrouvait directement liée aux pages du cache contenant les données du fichier système.
Authentification et écriture en dehors des limites de la mémoire
La cause principale de cette vulnérabilité réside dans le comportement anormal de l'algorithme d'authentification. Contrairement aux autres routines cryptographiques qui respectent scrupuleusement les limites de leurs tampons cibles, cet algorithme spécifique utilise la mémoire utilisateur comme espace de travail temporaire (bloc-notes) pour réorganiser les séquences d'octets lors du calcul des étiquettes d'authentification.
Lors de ce processus, l'algorithme écrit quatre octets au-delà des limites de la zone de sortie. Grâce à l'optimisation sur place et à la chaîne de références créée par `splice()`, cette écriture, en apparence anodine, franchit la limite de la mémoire utilisateur et est directement placée dans la page du cache du noyau associée au fichier traité.
Cette chaîne de failles logiques permet à un attaquant de modifier arbitrairement quatre octets à des positions spécifiques dans le cache de pages de n'importe quel fichier lisible. En envoyant une série de requêtes calculées, un attaquant peut injecter du code malveillant dans la version en mémoire de fichiers exécutables critiques dont le bit SUID est activé, comme l'outil de changement d'utilisateur.
Comme toutes les opérations de lecture interrogent d'abord le cache de pages, lors du prochain appel à l'utilitaire légitime, le système exécutera le code injecté depuis la mémoire, octroyant ainsi instantanément des privilèges root sans jamais modifier le fichier physique sur le disque dur. Plus alarmant encore, l'isolation des conteneurs partageant le cache de pages de l'hôte sous-jacent, cette vulnérabilité constitue une porte d'entrée directe pour s'échapper des environnements virtualisés tels que les clusters Kubernetes et compromettre le nœud principal.
Solutions d'urgence et d'atténuation
Compte tenu de la gravité de cette faille, les équipes de maintenance ont déployé des mises à jour d'urgence, dont la solution définitive consiste à annuler l'optimisation en place dans le fichier algif_aead.c, en séparant strictement les listes de mémoire source et de destination afin d'empêcher les pages de cache de se retrouver dans des chemins accessibles en écriture.
Ces correctifs ont déjà été intégrés aux noyaux 6.18.22, 6.19.12 et 7.0, et sont en cours de rétroportage vers les branches à support long terme. Pour les administrateurs qui ne peuvent pas redémarrer ou mettre à jour immédiatement leurs serveurs, il est recommandé de désactiver le module noyau algif_aead s'il a été compilé en externe, ou de restreindre fortement la création de sockets AF_ALG à l'aide de politiques de sécurité telles que SELinux, un système de protection qui, par exemple, a permis de préserver les appareils Android actuels de cette menace.
Enfin, si vous souhaitez en savoir plus, vous trouverez les détails en suivant ce lien.