CVE-2026-31431 (Copy Fail) — Analyse et remédiation sur Debian/Ubuntu

Le 29 avril 2026, la société de sécurité Theori a divulgué publiquement CVE-2026-31431, surnommée Copy Fail : une vulnérabilité d’escalade de privilèges locale de haute sévérité (CVSS 7.8) présente dans le noyau Linux depuis 2017. Un simple script Python de 732 octets suffit à obtenir les droits root sur pratiquement toutes les distributions Linux maintenues depuis cette date, dont Debian Bullseye, Bookworm, Trixie et toutes les versions actives d’Ubuntu jusqu’à la 25.10.

La faille réside dans le module algif_aead du sous-système cryptographique du noyau, accessible via l’interface AF_ALG (userspace crypto API). Elle permet à n’importe quel utilisateur local non privilégié d’effectuer une écriture contrôlée de 4 octets dans le page cache, c’est-à-dire la copie en mémoire de fichiers stockés sur disque — y compris des binaires setuid. Un attaquant peut ainsi remplacer du code en mémoire dans un exécutable privilégié et obtenir une élévation de privilèges au prochain lancement de ce binaire.

Face à l’ampleur de la surface d’attaque — des millions de serveurs, conteneurs et nœuds Kubernetes sont concernés — cet article détaille le mécanisme technique de la vulnérabilité, les versions affectées sur Debian et Ubuntu, les contre-mesures immédiates applicables sans redémarrage, et la procédure de remédiation définitive par mise à jour du noyau.

Comprendre la vulnérabilité

Le module algif_aead en cause

L’interface AF_ALG permet aux applications en espace utilisateur d’accéder aux primitives cryptographiques du noyau via des sockets. Le module algif_aead expose les opérations AEAD (Authenticated Encryption with Associated Data), notamment les algorithmes comme AES-GCM ou ChaCha20-Poly1305.

En 2017, une optimisation a été introduite : lors d’opérations AEAD, le noyau réutilisait le tampon source comme destination (in-place operation). Cette décision, anodine en apparence, permettait à un attaquant de provoquer une écriture contrôlée dans le page cache via une interaction subtile entre les sockets AF_ALG et l’appel système splice(). Le correctif kernel consiste simplement à revenir à des opérations hors-place (out-of-place) pour algif_aead, en réservant toujours ses propres tampons d’entrée/sortie.

Mécanisme d’exploitation

Le vecteur d’attaque est purement local (AV:L), ne requiert aucune interaction utilisateur, et ne nécessite que des privilèges bas (PR:L). La chaîne d’exploitation standard se déroule ainsi :

1. L’attaquant ouvre un socket AF_ALG de type aead en tant qu’utilisateur non privilégié.
2. Via splice(), il redirige des pages du page cache d’un fichier lisible — par exemple /usr/bin/sudo — vers l’opération cryptographique.
3. L’optimisation in-place provoque l’écriture d’une valeur contrôlée directement dans la page mémoire partagée.
4. Le binaire setuid corrompu en mémoire est exécuté : l’attaquant obtient les droits root.

La particularité la plus préoccupante est que la même primitive fonctionne à travers les frontières des conteneurs, car le page cache est partagé entre l’hôte et les conteneurs sans isolation supplémentaire. Un conteneur compromis peut ainsi attaquer l’hôte ou d’autres conteneurs.

Distributions et versions affectées

Debian

Toutes les branches stables actuelles de Debian sont affectées. Voici l’état des correctifs publiés :

Ubuntu

Les versions LTS et intermédiaires suivantes sont vulnérables : 18.04 (Bionic), 20.04 (Focal), 22.04 (Jammy), 24.04 (Noble) et 25.10 (Questing). Ubuntu 26.04 LTS (Resolute) n’est pas affecté. Canonical a publié les avis USN-8226-1 et USN-8226-2 le 30 avril 2026.

Pour vérifier si votre noyau est exposé :

# Afficher la version du noyau en cours
uname -r

# Lister les paquets noyau installés
dpkg -l 'linux-image*' | grep ^ii

# Vérifier si le module algif_aead est chargé
grep -qE '^algif_aead ' /proc/modules 
  && echo "Module CHARGÉ — système exposé" 
  || echo "Module absent — non exposé ou déjà mitigé"

Mitigation d’urgence sans redémarrage

Si vous ne pouvez pas appliquer immédiatement la mise à jour du noyau, deux approches permettent de bloquer l’exploitation sans redémarrage.

Désactiver le module algif_aead (module chargeable)

Sur la majorité des systèmes Debian/Ubuntu, algif_aead est compilé en module (CONFIG_CRYPTO_USER_API_AEAD=m). Vous pouvez le blacklister et le décharger :

# Blacklister le chargement futur du module
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf

# Décharger le module s'il est actif
sudo rmmod algif_aead 2>/dev/null && echo "Module déchargé" || echo "Module non chargé ou intégré au noyau"

# Mettre à jour l'initramfs
sudo update-initramfs -u

Attention : si le module est compilé directement dans le noyau (CONFIG_CRYPTO_USER_API_AEAD=y), les règles modprobe.d sont sans effet. Dans ce cas, utilisez le paramètre de démarrage suivant et redémarrez :

# Pour les systèmes avec GRUB (ajouter au paramètre GRUB_CMDLINE_LINUX)
sudo nano /etc/default/grub
# Ajouter : initcall_blacklist=algif_aead_init
# Puis :
sudo update-grub
sudo reboot

Blocage via seccomp (environnements conteneurisés)

Pour les workloads Docker ou Podman, l’exploitation nécessite d’ouvrir un socket AF_ALG. Un profil seccomp qui bloque l’appel socket(AF_ALG, ...) neutralise la faille même sur noyau non patché :

# Lancer un conteneur Docker avec le blocage AF_ALG
docker run --security-opt seccomp=/etc/docker/seccomp-no-afalg.json monimage

# Vérifier les politiques seccomp actives sur un conteneur en cours
docker inspect --format='{{.HostConfig.SecurityOpt}}' mon_conteneur

Remédiation définitive — mise à jour du noyau

Sur Debian

# Mettre à jour les sources et appliquer les correctifs de sécurité
sudo apt update
sudo apt upgrade linux-image-$(uname -r) linux-headers-$(uname -r)

# Ou mise à jour complète recommandée
sudo apt full-upgrade

# Redémarrer sur le nouveau noyau
sudo reboot

# Après redémarrage, vérifier la version corrigée
uname -r

Versions cibles après mise à jour :

• Bullseye : 5.10.251-4 ou supérieur
• Bookworm : 6.1.170-3 ou supérieur
• Trixie : 6.12.86-1 ou supérieur

Sur Ubuntu

Canonical a d’abord publié une mise à jour du paquet kmod qui désactive automatiquement le chargement de algif_aead, avant les mises à jour noyau complètes :

# Étape 1 : mettre à jour kmod en priorité (mitigation immédiate)
sudo apt update
sudo apt install --only-upgrade kmod

# Étape 2 : mise à jour complète du noyau
sudo apt upgrade
sudo reboot

# Vérification post-redémarrage
uname -r
dpkg -l kmod | grep ^ii

Vérifier l’efficacité de la correction

Une fois le noyau mis à jour et le système redémarré, confirmez que la faille est résolue :

# Vérifier que le module algif_aead n'est plus chargeable
python3 -c "import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); print('Vulnérable')" 2>/dev/null 
  || echo "Socket AF_ALG refusé — mitigation active"

# Vérifier l'absence du module dans les modules actifs
lsmod | grep algif_aead && echo "ATTENTION : module encore actif" || echo "Module absent — OK"

# Contrôler la version du noyau installé vs. versions vulnérables
uname -r

À lire également

• nftables en pratique — remplacer iptables sur Debian/Ubuntu
• Sécurité Linux — Firewall iptables et nftables
• Podman : alternative rootless à Docker — installation et migration
• Authentification par clé publique sur un serveur SSH

Références

• Ubuntu — Fixes available for CVE-2026-31431 (Copy Fail)
• CERT-EU — High Vulnerability in the Linux Kernel (« Copy Fail »)
• Debian Security Tracker — CVE-2026-31431
• NVD — CVE-2026-31431 Detail
• Microsoft Security Blog — CVE-2026-31431 Copy Fail