À propos de la vulnérabilité

CVE-2026-31431, publiquement désignée sous le nom de Copy Fail, est une vulnérabilité d'élévation de privilèges locale dans le noyau Linux associée au module algif_aead, qui implémente l'interface AEAD de l'API crypto du noyau en espace utilisateur via AF_ALG.

En termes pratiques, le problème permet à un utilisateur local à faibles privilèges d'abuser d'un défaut logique dans le chemin de gestion de la mémoire de ce sous-système et d'étendre l'impact jusqu'à un compromis complet de l'intégrité du système. Le score publié par kernel.org et reflété dans la NVD est CVSS 7.8, avec le vecteur AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, ce qui signifie que l'attaque nécessite une exécution locale mais a un impact élevé sur la confidentialité, l'intégrité et la disponibilité.

Quand elle a été introduite et divulguée

• La cause racine exploitable a été introduite dans le noyau en 2017, lorsqu'une optimisation en place a été ajoutée à algif_aead.
• La CVE a été publiée dans la NVD le 22 avril 2026.
• Une divulgation publique plus large du problème, sous le nom Copy Fail et avec une preuve de concept publique, a eu lieu le 29 avril 2026.
• Le correctif principal en amont a été validé le 1er avril 2026, avant la divulgation publique aux utilisateurs finaux.

Ce qu'elle exploite

Selon les avis techniques publiés, le défaut repose sur la combinaison de :

• l'interface AF_ALG du noyau
• le module algif_aead
• une optimisation d'opération en place introduite en 2017
• l'enchaînement de cette interface avec splice()

Le résultat pratique est la capacité pour un processus local d'effectuer une petite écriture contrôlée dans des pages adossées au cache de pages de fichiers lisibles. Dans des conditions favorables, cela suffit à transformer un point d'appui local limité en élévation de privilèges root.

Comment cela affecte l'entreprise

Le risque réel n'est pas simplement « d'exécuter un noyau Linux vulnérable », mais de permettre à du code local à faible confiance d'atteindre ce chemin du noyau. Dans les environnements d'entreprise, cela signifie généralement une exposition plus élevée sur :

• les serveurs multi-utilisateurs
• les hôtes de rebond et bastions
• les exécuteurs CI/CD
• les charges de travail conteneurisées exécutant du code non fiable
• les clusters Kubernetes
• les machines virtuelles hébergeant de l'automatisation, des agents, des plugins ou des tâches tierces

Si un attaquant dispose déjà d'une forme d'exécution locale, même sans root, cette CVE peut devenir l'étape suivante vers le compromis de l'hôte. En pratique, cela élargit le risque de :

• prise de contrôle complète du serveur
• modification de binaires ou d'artefacts locaux
• vol d'identifiants, de jetons et de secrets résidents
• mouvement latéral vers d'autres actifs
• sabotage des pipelines et des chaînes de construction

À quoi sert le module algif_aead

algif_aead fait partie de l'interface crypto du noyau en espace utilisateur (AF_ALG). Il permet aux applications d'utiliser les primitives cryptographiques du noyau via des sockets, en particulier les opérations AEAD (chiffrement authentifié avec données associées).

Ce module n'est généralement pas essentiel pour la plupart des charges de travail serveur standard. Selon les recommandations d'atténuation publiées par CERT-EU, désactiver algif_aead comme atténuation temporaire :

• ne devrait pas affecter dm-crypt ou LUKS
• ne devrait pas affecter kTLS
• ne devrait pas affecter IPsec/XFRM
• ne devrait pas affecter OpenSSL, GnuTLS, NSS ou SSH en usage standard

En revanche, sa désactivation peut affecter :

• les applications explicitement configurées pour utiliser le moteur afalg
• les logiciels qui ouvrent des sockets AF_ALG directement
• les intégrations personnalisées qui utilisent aead, skcipher ou hash via l'API crypto du noyau

En d'autres termes, pour la plupart des hôtes d'entreprise, bloquer le module tend à avoir un faible impact. Dans les appliances, les piles cryptographiques personnalisées ou les chemins logiciels fortement optimisés, l'impact doit être validé avant le déploiement.

Impact opérationnel de la désactivation du module

Bloquer le module réduit immédiatement l'exposition, mais cela comporte des compromis :

• les applications qui dépendent de AF_ALG peuvent échouer au démarrage ou perdre l'accélération cryptographique adossée au noyau
• les charges de travail personnalisées peuvent échouer uniquement à l'exécution, pas au démarrage
• si le module est déjà chargé, l'atténuation n'est complète qu'après un déchargement réussi ou un redémarrage

Pour les environnements de production, l'approche la plus sûre consiste à appliquer l'atténuation dans une fenêtre de maintenance contrôlée et à valider les applications critiques ensuite.

Correctif permanent recommandé

La mise sur liste noire du module n'est qu'une atténuation temporaire. Le correctif permanent est :

1. installer un noyau corrigé fourni par le distributeur
2. redémarrer l'hôte afin que le nouveau noyau soit réellement chargé
3. valider que l'hôte n'est plus signalé comme affecté
4. décider ensuite seulement si la liste noire du module doit rester en place

Mesures supplémentaires recommandées :

• prioriser le correctif sur les hôtes avec des utilisateurs locaux, des conteneurs ou une exécution de code non fiable
• restreindre la création de sockets AF_ALG avec seccomp dans les conteneurs et les pipelines lorsque cela est applicable
• examiner où afalg ou l'API crypto du noyau est explicitement utilisée
• maintenir un inventaire des versions du noyau et des redémarrages en attente
• traiter les exécuteurs CI/CD et les nœuds Kubernetes comme une priorité élevée

Ce que le script vérifie

Le script inspecte :

• le nom d'hôte
• la version du noyau en cours d'exécution
• le système d'exploitation via /etc/os-release
• la présence du module algif_aead
• si le module est actuellement chargé
• si le module est bloqué par une règle modprobe
• si l'hôte nécessite un redémarrage (/var/run/reboot-required)
• l'état signalé par Ubuntu Pro via pro fix CVE-2026-31431 --dry-run, lorsque disponible

Sur cette base, il renvoie l'une des classifications suivantes :

• PATCHED_OR_NOT_AFFECTED
• LIKELY_NOT_VULNERABLE
• MITIGATED
• VULNERABLE_MODULE_LOADED
• POTENTIALLY_VULNERABLE
• UNKNOWN

Logique de classification

En résumé :

• Si l'outillage Ubuntu indique que l'hôte n'est pas affecté ou est déjà corrigé, le statut devient PATCHED_OR_NOT_AFFECTED.
• Si le module algif_aead n'existe pas dans le noyau actuel, le statut tend vers LIKELY_NOT_VULNERABLE.
• Si le module existe mais est bloqué et non chargé, le statut devient MITIGATED.
• Si Ubuntu indique que l'hôte est affecté et que le module est chargé, le statut devient VULNERABLE_MODULE_LOADED.
• Si le module existe et est chargeable mais que l'état du correctif ne peut pas être confirmé, le statut devient POTENTIALLY_VULNERABLE.

Prérequis

• Bash
• modinfo
• modprobe
• lsmod
• awk
• grep
• hostname
• uname
• apt-get pour --update
• sudo lors d'une exécution en tant qu'utilisateur non root
• pro facultativement, pour enrichir l'analyse sur Ubuntu

Utilisation

Si le fichier du script est nommé check_cve_2026_31431.sh :

Vérification par défaut

Exemple de sortie :

Sortie JSON

Exemple :

Cette sortie est utile pour l'automatisation, l'inventaire des actifs et les pipelines de conformité.

Atténuation

Le mode --mitigate crée le fichier :

Avec le contenu suivant :

Ensuite, le script tente de retirer le module de la mémoire avec :

Utilisation :

Si l'utilisateur n'est pas root, le script tentera d'utiliser sudo.

Mise à jour

Le mode --update exécute :

Utilisation :

Ce mode tente de mettre à niveau les paquets liés au noyau sur les systèmes basés sur Debian et Ubuntu. Dans d'autres environnements, cette étape peut ne pas s'appliquer.

Aide

Sortie :

Limitations importantes

• Le script utilise des heuristiques. Il ne prouve pas l'exploitation ; il estime l'exposition et l'état d'atténuation.
• Les champs ubuntu_affected et fix_available dépendent de la présence de la commande pro.
• L'étape --update utilise des modèles de paquets orientés Ubuntu et Debian et peut ne pas couvrir tous les noyaux personnalisés.
• Sur certaines distributions, le module peut exister avec un comportement différent de celui attendu par le script.
• Bloquer le module peut nécessiter un redémarrage dans certains environnements pour garantir un état cohérent.

Flux de travail recommandé

1. Exécuter --check pour évaluer l'hôte.
2. Si le module est disponible et qu'aucun correctif n'est appliqué, exécuter --mitigate.
3. Exécuter --update ou appliquer la mise à jour officielle du fournisseur.
4. Redémarrer l'hôte si nécessaire.
5. Exécuter --check --json pour valider l'état final et conserver les preuves.

Remarque

Pour plus de clarté dans la publication, le script devrait idéalement utiliser un nom descriptif tel que :

Crédits

Matériel organisé et publié avec le crédit de SEC17.

Site web officiel :

• https://sec17.com