Depuis quelques jours, Copy Fail fait parler d’elle dans la communauté Linux. Il s’agit d’une vulnérabilité du noyau Linux — la CVE-2026-31431 — qui, contrairement à la plupart des CVEs, dispose d’un proof-of-concept public redoutablement simple. J’ai voulu la corriger sur mon laptop Tuxedo OS. La mitigation officielle n’a pas fonctionné. Voici pourquoi, et comment s’en sortir.

C’est quoi Copy Fail ?

Copy Fail est un bug logique dans le template cryptographique authencesn du noyau Linux : un utilisateur local non-privilégié peut écrire 4 octets de façon contrôlée dans le page cache de n’importe quel fichier lisible. Comme le noyau passe par ce cache pour charger les binaires, c’est une modification effective sans toucher le disque — et sans déclencher inotify.

C’est une faille logique pure, déterministe, sans race condition, exploitable avec un simple script Python standard. CVSS 7.8, PoC public. Ça mérite d’être corrigé.

La mitigation officielle

Au 30 avril 2026, aucune distribution n’a encore publié un noyau patché. Le correctif upstream (commit a664bf3d603d de Herbert Xu) existe depuis le 1er avril, mais les backports sont en attente chez Ubuntu, Red Hat et les autres.

En attendant, la mitigation recommandée est de désactiver le module algif_aead :

# Rendre le blocage permanent (survit au reboot)
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

# Décharger le module immédiatement
sudo rmmod algif_aead 2>/dev/null || true

J’ai appliqué ça. Le PoC a continué de fonctionner.

Pourquoi la mitigation officielle échoue

Trois problèmes combinés. D’abord, le rmmod masqué par || true a silencieusement raté — algif_aead est resté chargé en mémoire. Ensuite, la mitigation ne bloque qu’algif_aead, alors que le PoC peut basculer sur algif_skcipher ou algif_hash. Enfin et surtout, ces trois modules partagent la même socket de base af_alg : c’est elle qu’il faut bloquer, pas ses dépendants un par un.

La solution complète

Étape 1 — Décharger tous les modules dans le bon ordre

Les dépendants d’abord, sinon rmmod refusera :

sudo rmmod algif_aead algif_skcipher algif_hash af_alg

Si l’un refuse (module en cours d’utilisation), identifier le processus fautif :

sudo lsof | grep -E 'algif|af_alg'

Étape 2 — Bloquer tous les modules + af_alg de façon permanente

Créer /etc/modprobe.d/disable-algif.conf avec le contenu suivant :

sudo tee /etc/modprobe.d/disable-algif.conf << 'EOF'
install algif_aead /bin/false
install algif_skcipher /bin/false
install algif_hash /bin/false
install algif_rng /bin/false
install algif_akcipher /bin/false
install af_alg /bin/false
EOF

Bloquer af_alg est le plus robuste : même si un nouveau module algif_* apparaissait, il ne pourrait pas se charger sans sa dépendance racine.

Vérification

lsmod | grep algif   # doit retourner vide

Puis relancer le PoC. La bonne réponse est :

OSError: [Errno 97] Address family not supported by protocol

L’erreur 97 (EAFNOSUPPORT) signifie que la socket AF_ALG est inaccessible au niveau kernel — le PoC plante dès la première ligne, avant même d’atteindre algif_aead. La mitigation est complète.

Ce que ça ne casse pas

Ce blocage n’affecte pas : dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, SSH. Il peut théoriquement gêner une application configurée explicitement pour utiliser le moteur OpenSSL afalg ou qui ouvre directement des sockets aead/skcipher/hash — ce qui est rarissime sur un laptop grand public.

La suite : le patch kernel

Dès qu’Ubuntu publiera un noyau incorporant le commit a664bf3d603d :

sudo apt update && sudo apt upgrade
sudo reboot
# Vérifier que le nouveau noyau est actif
uname -r
# Vérifier que le patch est bien inclus
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i "a664bf3d\|CVE-2026-31431"
# Une fois confirmé, retirer la mitigation modprobe
sudo rm /etc/modprobe.d/disable-algif.conf

Le suivi de disponibilité : ubuntu.com/security/CVE-2026-31431.