CVE-2026-31431 Copy Fail : LPE kernel Linux et mitigation Ansible

Le 30 avril 2026, Taeyang Lee de Theori et le Xint Code Research Team ont divulgué CVE-2026-31431, surnommée « Copy Fail » : une élévation de privilèges locaux dans le kernel Linux qui touche, par défaut, l'ensemble des distributions majeures sorties à partir de 2017. La primitive est si propre qu'un simple compte de service, www-data, mysql, ou n'importe quel processus dans une application web compromise, passe à root en quelques appels système.

Chez AESTECHNO, bureau d'études électronique basé à Montpellier, nous avons publié dans la foulée un playbook Ansible open source pour détecter et appliquer la mitigation officielle sur un parc hétérogène : github.com/aestechno/cve-2026-31431-ansible. Sur les images Linux embarqué que nous livrons (BSP Yocto, Ubuntu Core, Debian-based), nous avons audité la configuration kernel CONFIG_CRYPTO_USER_API_AEAD à la sortie de la divulgation : sur l'ensemble des BSP examinés à ce jour, l'option est activée par défaut. Ce guide explique ce qui a été trouvé, pourquoi la solution évidente modprobe blacklist ne suffit pas, et comment couvrir une flotte Linux, serveurs backend, frontaux web, hôtes de conteneurs, passerelles IoT, sans casser la production.

Que fait « Copy Fail » exactement

CVE-2026-31431 est une corruption mémoire dans algif_aead, le module qui expose les algorithmes de chiffrement authentifié (AEAD) du kernel Linux à l'espace utilisateur via l'interface socket AF_ALG. Cette interface, pensée pour offrir aux applications l'accès au sous-système crypto sans dupliquer les implémentations, devient ici un canal d'écriture arbitraire dans le kernel.

Le scénario d'attaque est minimal. Un attaquant disposant déjà d'une exécution de code locale, par exemple via une RCE dans une application PHP, un conteneur multi-tenant mal isolé, ou un compte SSH limité, ouvre une socket AF_ALG, l'attache à l'algorithme aead, puis enchaîne quelques setsockopt/sendmsg qui déclenchent le bug. Aucune interaction utilisateur, aucune condition de course délicate à gagner, aucune dépendance à CAP_* particulière. La plupart des comptes de service Linux standards (www-data, mysql, postgres, redis) suffisent.

Cette propriété d'exploit fiable, selon Tenable dans sa FAQ technique, le rend immédiatement utilisable comme deuxième étage dans une chaîne d'attaque : la première brèche peut rester de bas niveau (un endpoint web vulnérable, un secret de CI exposé), Copy Fail se charge de la promotion en root. La publication simultanée d'avis Ubuntu, Debian et CERT-EU (SA 2026-005), comme le souligne CloudLinux dans sa documentation de mitigation, indique une divulgation coordonnée entre les distributeurs Linux principaux.

Pourquoi tout votre parc Linux est concerné

Le module algif_aead est livré activé par défaut dans la quasi-totalité des distributions Linux majeures à partir de 2017. Cela couvre Ubuntu 18.04 et postérieures, Debian 10 et postérieures, la famille RHEL 8/9 (et dérivés AlmaLinux, Rocky), SUSE Linux Enterprise Server, ainsi que la plupart des images conteneur de base Alpine adossées au kernel hôte. La documentation officielle du kernel décrit l'interface AF_ALG comme un canal d'accès userspace au sous-système crypto, ajouté pour rendre certains accélérateurs matériels accessibles sans pilote dédié.

Le tableau suivant résume la situation distribution par distribution, déterminante pour choisir la bonne mitigation, comme on le verra plus bas :

Famille	Configuration algif_aead	modprobe blacklist efficace ?	Mitigation universelle
Debian 10-12 / Ubuntu 18.04-24.04	Module dynamique (=m)	Oui (mais pas suffisant)	Cmdline kernel
RHEL 8/9 / AlmaLinux / Rocky	Compilé en dur (=y)	Non	Cmdline kernel
SUSE SLE 15	Module dynamique (=m)	Oui (mais pas suffisant)	Cmdline kernel
Alpine + kernel hôte	Hérité de l'hôte	Dépend de l'hôte	Cmdline kernel hôte
Yocto BSP custom	Variable (=y typique)	Non si =y	Cmdline kernel

Concrètement, dans une infrastructure typique backend / frontend / IoT, les actifs exposés sont :

• Serveurs backend exécutant des applicatifs métier, des bases de données, des files de messages : chaque processus de service est un point de départ potentiel.
• Frontaux web et reverse proxies (NGINX, HAProxy, Traefik). Une RCE dans un applicatif PHP/Node/Python derrière le proxy donne accès à un shell www-data, qui suffit.
• Hôtes de conteneurs (Docker, containerd, Kubernetes nodes) : un échappement, même limité à un namespace utilisateur, atteint l'interface AF_ALG du kernel partagé.
• Passerelles IoT et edge servers sous Ubuntu Core, Debian, ou Yocto avec kernel Linux mainline ; les flottes industrielles sont particulièrement à risque parce que les fenêtres de patch y sont longues.
• Postes développeurs et runners CI où des secrets de production transitent : un compte build compromis qui passe root est un compromis de chaîne d'approvisionnement.

Lors de nos missions de conception de systèmes embarqués Linux, nous croisons régulièrement des passerelles dont le kernel n'a pas été reconstruit depuis 18 mois. Pour ces actifs, le délai entre la divulgation et la disponibilité d'un kernel patché signé par le fournisseur est précisément la fenêtre que cette mitigation est conçue à fermer.

La mitigation : initcall_blacklist=algif_aead_init

La mitigation universelle consiste à ajouter le paramètre initcall_blacklist=algif_aead_init à la ligne de commande du kernel, puis à redémarrer. À l'amorce, le kernel ignore l'initcall qui enregistre l'algorithme aead auprès du sous-système crypto socket. Le code vulnérable reste présent dans l'image kernel, mais il n'est jamais atteint : socket(AF_ALG, ..., "aead") retourne immédiatement ENOENT.

Le principe sous-jacent, retirer la surface d'attaque plutôt que tenter de corriger le bug à chaud, est exactement celui que nous appliquons dans nos audits de cybersécurité produit : un service inaccessible est un service non exploitable. CloudLinux et le CERT-EU SA 2026-005 recommandent tous deux cette même mitigation comme solution intermédiaire en attendant les kernels patchés.

L'impact sur les performances est nul pour la quasi-totalité des charges de travail. AF_ALG est très peu utilisé en pratique : OpenSSL, libsodium, GnuTLS et la plupart des bibliothèques crypto userland disposent de leurs propres implémentations optimisées (AES-NI, AVX2) qui surpassent l'interface kernel. Les rares consommateurs réels, certains agents cryptsetup, des outils de chiffrement disque spécifiques, utilisent algif_skcipher ou algif_hash, qui restent disponibles.

Pourquoi modprobe blacklist n'est pas la bonne réponse

Une réaction réflexe consiste à écrire blacklist algif_aead dans /etc/modprobe.d/. Cela fonctionne sur Debian et Ubuntu, où algif_aead est livré en module chargeable (.ko) et chargé à la demande. Mais sur la famille RHEL, RHEL 8/9, AlmaLinux 9, Rocky 9, ainsi que de nombreuses images cloud dérivées, algif_aead est compilé statiquement dans vmlinuz via CONFIG_CRYPTO_USER_API_AEAD=y.

Pour un module compilé en dur, la directive blacklist de modprobe n'a aucun effet : le code est déjà lié à l'image kernel et son initcall s'exécute au démarrage avant que /etc/modprobe.d ne soit lu. C'est précisément pour cela que le paramètre cmdline initcall_blacklist, géré par le boot du kernel lui-même, est la seule mitigation qui couvre uniformément les configurations modulaires et built-in.

Cette distinction modulaire-vs-built-in piège également les politiques d'audit automatisé. Un scanner de configuration qui valide la présence de blacklist algif_aead sans vérifier /proc/cmdline donnera un faux compliant sur la moitié de votre flotte. Pour une vérification fiable, c'est cat /proc/cmdline | grep initcall_blacklist=algif_aead_init qui fait foi, kernel par kernel.

Détecter et appliquer à l'échelle : notre playbook Ansible

Sur un parc de plus de quelques machines, l'opération doit être automatisée et auditée. Nous avons publié sous licence Beerware un playbook Ansible qui couvre cette opération de bout en bout : github.com/aestechno/cve-2026-31431-ansible. Le code est court, sans dépendances de collections externes, et conçu pour ne jamais redémarrer une machine sans intervention humaine.

Le playbook supporte les deux familles dominantes, Debian/Ubuntu via édition de /etc/default/grub + update-grub, et RHEL via grubby --update-kernel=ALL --args, et passe sur les autres familles avec un statut explicite plutôt qu'un échec silencieux. Tests d'intégration continue exécutés sur debian:12, ubuntu:22.04, ubuntu:24.04 et almalinux:9 à chaque commit.

Trois invocations couvrent le cycle complet :

  # 1. Détection (read-only) : produit un rapport par hôte
  ansible-playbook -i inventory check_cve_2026_31431.yml

  # 2. Stage de la mitigation sur un hôte canari (jamais de reboot auto)
  ansible-playbook -i inventory --limit canari.example.com \
    -e apply_mitigation=true check_cve_2026_31431.yml

  # 3. Redémarrage par votre mécanisme habituel, puis re-détection
  #    pour confirmer "Mitigation active: yes"

Le rapport par hôte distingue volontairement mitigation active (présent dans /proc/cmdline, donc effectif sur le kernel courant) de mitigation staged (présent dans GRUB mais en attente de redémarrage). Cette distinction est ce qui permet à un opérateur d'orchestrer les redémarrages au rythme de ses fenêtres de maintenance, plutôt que de subir un reboot d'inventaire.

Chez AESTECHNO, nous avons constaté que les configurations kernel par défaut livrées avec les BSP Yocto, Ubuntu Core et les images Debian-based activent uniformément CONFIG_CRYPTO_USER_API_AEAD : sur 100 % des BSP que nous avons examinés à la sortie de la divulgation, l'option est compilée. Sur un projet récent de BSP Yocto pour module NVIDIA Jetson Orin NX livré au premier trimestre 2026, nous avons testé l'intégration de la mitigation directement dans la chaîne U-Boot : la variable bootargs accepte le flag sans modification du device tree. Dans notre pratique d'audit kernel, nous accompagnons les équipes ops qui doivent documenter leur exposition pour leur reporting Cyber Resilience Act, et nous recommandons systématiquement de coupler la mitigation à un suivi de configuration GitOps : un détecteur de dérive automatique évite qu'une réinstallation laisse retomber le flag sans alerte.

Procédure de roll-out recommandée

Un déploiement sécurité sur un parc en production se planifie comme un déploiement applicatif : par vagues, avec rollback explicite, et avec un signal de validation entre deux vagues. La méthode que nous suivons sur les flottes que nous opérons est la suivante.

1. Inventaire. Lancer la détection en mode read-only sur l'ensemble du parc. La sortie attendue est une liste exhaustive de chaque hôte avec son statut : active, staged, vulnerable, unreachable. Les unreachable sont traités comme vulnérables jusqu'à preuve du contraire.
2. Canari. Choisir un hôte représentatif, même distribution majoritaire, même rôle applicatif, et y stager la mitigation avec --limit. Redémarrer en fenêtre de maintenance basse activité, valider que les services applicatifs remontent normalement, et que /proc/cmdline contient bien le flag.
3. Vague de production. Étendre par lots de 10 % à 25 % du parc, en respectant les fenêtres de maintenance définies par les SLA. Les redémarrages restent manuels ou orchestrés par votre outil de gestion de fleet (kured pour Kubernetes, Spacewalk/Foreman pour la famille RHEL).
4. Validation finale. Re-détecter l'ensemble du parc 48 h après la dernière vague. Tout hôte resté staged sans active trahit un reboot manqué et doit remonter en alerte.

Cette discipline, détecter, stager, redémarrer, re-vérifier, recoupe les principes que nous appliquons dans nos pipelines de DevOps embarqué et CI/CD pour produits industriels : aucun changement de production sans signal de validation explicite.

CVE-2026-31431 dans le contexte du Cyber Resilience Act

Pour les fabricants de produits comportant des éléments numériques distribués en UE, CVE-2026-31431 tombe directement dans le périmètre du Cyber Resilience Act (CRA, règlement 2024/2847). Le règlement CRA, applicable à partir de décembre 2027 selon l'ENISA, exige un reporting des vulnérabilités exploitées sous 24 heures, une politique de Coordinated Vulnerability Disclosure (CVD) alignée sur RFC 9116, et une traçabilité des composants via un Software Bill of Materials (SBOM) au format CycloneDX 1.5 ou SPDX 2.3.

Concrètement, d'après l'ENISA, un produit IoT commercialisé qui embarque un kernel Linux affecté doit être en mesure d'identifier l'exposition via son SBOM, d'émettre une notification au coordinateur national et de proposer une mitigation à ses utilisateurs dans les 24 heures suivant la confirmation d'exploitation active. Le playbook Ansible que nous publions répond à la partie « démontrer la mitigation » de cette obligation : il génère un rapport par hôte que l'on peut joindre à un dossier CRA. Pour les opérateurs de services essentiels couverts par NIS2, l'obligation est analogue avec des seuils de criticité légèrement différents.

Quand retirer la mitigation

La mitigation cmdline est une mesure intermédiaire. Une fois que votre fournisseur de kernel, Canonical pour Ubuntu, Red Hat pour RHEL, le mainteneur de votre BSP Yocto pour les produits embarqués, a publié un kernel patché et que vous avez redémarré dessus, le flag peut être retiré sans risque. Suivez les pages de tracking officielles : Ubuntu, Debian Security Tracker, et les bulletins équivalents Red Hat / SUSE.

Le retrait se fait avec deux one-liners, symétriques de la mitigation :

  # Debian / Ubuntu
  sudo sed -i 's/ initcall_blacklist=algif_aead_init//' /etc/default/grub
  sudo update-grub
  sudo reboot

  # RHEL family
  sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
  sudo reboot

Pour un parc, automatiser ce retrait dans une seconde passe Ansible une fois le patch kernel déployé évite que le flag ne reste « collé » dans la configuration de boot pendant des années : un cas de dérive de configuration que nous voyons régulièrement sur des serveurs hérités.

FAQ

CVE-2026-31431 affecte-t-elle un serveur dont seul SSH est exposé ?

Oui, dès qu'un compte non root peut s'y connecter. La faille étant une élévation locale de privilèges, le vecteur d'entrée, SSH avec utilisateur restreint, conteneur, application web, runner CI, n'a pas d'importance : ce qui compte est qu'un processus userland puisse ouvrir une socket AF_ALG. Un serveur multi-utilisateur ou multi-tenant doit être considéré comme prioritaire.

Le flag initcall_blacklist dégrade-t-il les performances ?

Non, pour la quasi-totalité des charges de travail. Les bibliothèques crypto userland (OpenSSL, libsodium, GnuTLS) utilisent leurs propres implémentations optimisées AES-NI/AVX2 et n'appellent pas AF_ALG. Seuls quelques outils spécifiques (certains agents cryptsetup avec backend kernel) pourraient être impactés ; ils utilisent en pratique algif_skcipher et algif_hash, qui restent fonctionnels.

Le kernel patché est-il déjà disponible pour ma distribution ?

La fenêtre de publication varie selon les distributions. Suivez en temps réel les pages de tracking : Ubuntu CVE-2026-31431, Debian Security Tracker, ainsi que les bulletins Red Hat et SUSE. La mitigation cmdline reste valide tant que vous n'avez pas redémarré sur un kernel marqué fixed par votre fournisseur.

Le playbook fonctionne-t-il sur ARM (Raspberry Pi, Jetson, passerelles industrielles) ?

Oui. La mitigation porte sur la ligne de commande kernel et sur la chaîne GRUB/grubby ; elle est indépendante de l'architecture CPU. Les images Raspberry Pi OS (Debian) sont gérées par le chemin Debian family du playbook ; les BSP Yocto pour NVIDIA Jetson ou cartes industrielles ARM peuvent utiliser GRUB ou un bootloader custom (U-Boot, extlinux), auquel cas l'édition se fait dans /boot/extlinux/extlinux.conf ou l'environnement U-Boot, adaptable à partir de notre code.

Faut-il appliquer la mitigation et attendre le patch, ou choisir ?

Les deux, dans cet ordre. La mitigation cmdline ferme la surface d'attaque immédiatement, sans dépendre du calendrier de votre fournisseur. Le patch kernel, lui, corrige la cause racine et permet à terme de retirer le flag. Une politique de sécurité produit alignée sur le Cyber Resilience Act exige les deux : une mesure compensatoire documentée pendant la fenêtre d'exposition, suivie du correctif définitif.

Articles Connexes

• Cybersécurité IoT industriel : menaces et solutions
• Sécuriser un produit IoT : de la conception au déploiement
• Cyber Resilience Act (CRA) : mise en conformité IoT
• Quelle distribution Linux embarqué : Ubuntu, Alpine ou Yocto ?
• DevOps embarqué : CI/CD et tests automatisés

Crédit découverte : Taeyang Lee (Theori) pour la vulnérabilité, Xint Code Research Team pour la chaîne d'exploitation. Notre playbook automatise la mitigation qu'ils recommandent.