CopyFail & DirtyFrag : quand "Linux c'est secure" prend un coup dans les dents

Voici comment ça s’est passé côté infra, et ce que j’en retiens.

Ce qui s'est passé

CopyFail (CVE-2026-31431)

Le 29 avril 2026, une vulnérabilité critique sort au grand jour sous le nom de CopyFail, référencée CVE-2026-31431. Et franchement, le concept est violent de simplicité : un utilisateur local, sans aucun privilège, peut devenir root sur une machine vulnérable. Pas d’accès distant. Pas d’exploit ésotérique. Un script Python de 732 lignes suffit, publié quasiment dans la foulée.

La faille se cache dans le module algif_aead du noyau Linux, celui qui gère certaines opérations cryptographiques via l’interface AF_ALG. Une « optimisation de performance » glissée en 2017 a laissé une brèche dans la gestion mémoire. Résultat : quasiment tous les noyaux Linux compilés depuis 2017 sont concernés. Ubuntu, Debian, RHEL, AlmaLinux, Rocky Linux, clairement, personne n’est à l’abri.

Le 1er mai, la CISA ajoute officiellement CVE-2026-31431 à son catalogue des vulnérabilités activement exploitées. Là, tu comprends que ce n’est pas juste « une CVE de plus ».

Ce qui rend l’histoire encore plus marquante, c’est l’origine : c’est Xint Code, un agent IA développé par Theori, qui a repéré l’anomalie en analysant des millions de lignes de code du noyau. Une faille dormante depuis neuf ans, trouvée par une machine. On y revient plus bas.

DirtyFrag (CVE-2026-43284 / CVE-2026-43500)

Et comme si ça ne suffisait pas, avant même que la plupart des équipes aient eu le temps de patcher CopyFail, une deuxième faille débarque : DirtyFrag. Même famille, même impact, élévation de privilèges jusqu’à root, mais via la gestion des fragments mémoire et des caches réseau du noyau. Là encore, pratiquement toutes les distributions sont concernées.

Deux semaines, deux CVE critiques. Pour être honnête, le timing fait réfléchir.

Comment je l'ai appris

Comme beaucoup d’admins, j’ai un outil de veille automatique qui remonte les alertes CVE. CopyFail passe dans le flux. Je la vois. Je la note mentalement. Et je continue ma journée.

Ce qui déclenche vraiment la réaction, c’est le soir même : Yves Rougy, expert Linux avec 30 ans de pratique et 25 000 abonnés YouTube, fait un live dessus. En quelques minutes, tout devient limpide : l’exploit est public, fonctionnel, et trivial à utiliser. Là, tu arrêtes de « garder ça en tête » et tu passes en mode action.

La vraie leçon, elle est là : une veille ne sert à rien si tu ne lui donnes pas le poids qu’elle mérite. L’alerte était là. Je l’avais. Ce qui manquait, c’était le contexte, humain en l’occurrence, qui fait basculer une info « intéressante » en priorité opérationnelle.

L'inventaire et les premières actions

Tour du parc. Sans surprise : quasi tous les systèmes Linux de l’infrastructure sont concernés. Noyaux post-2017, distributions majeures, surface d’attaque large.

Le problème, c’est qu’au moment où je m’y mets, le patch noyau Ubuntu n’est pas encore disponible. Donc pas le choix, il faut appliquer le workaround en attendant.

Vérifier si vous êtes exposé

grep -qE '^algif_aead ' /proc/modules && echo "Module chargé : système exposé" || echo "Module absent : système non exposé"

Workaround immédiat (toutes distributions)

Désactiver le module algif_aead de façon persistante :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

Note pour les distributions RHEL-family (AlmaLinux, Rocky, CentOS...) : le module algif_aead est compilé directement dans le noyau (CONFIG_CRYPTO_USER_API_AEAD=y). La règle modprobe.d ne suffit pas : elle s’applique sans erreur, mais ne fait rien. Il faut passer par le paramètre de démarrage du noyau :

bashCopier

grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
reboot

Après redémarrage, vérifier avec cat /proc/cmdline que le paramètre est bien présent.

Ce workaround n’impacte pas LUKS, IPsec, SSH, OpenSSL, GnuTLS ni kTLS. Seules les applications qui utilisent explicitement le moteur afalg d’OpenSSL ou les sockets AF_ALG directement sont concernées, ce qui reste rare en production « classique ».

Patcher proprement une fois les correctifs disponibles

Ubuntu 24.04 LTS :

sudo apt update && sudo apt full-upgrade
sudo reboot

Le patch est disponible via le noyau 6.17.0-23 ou via la mise à jour du paquet kmod vers 31+20240202-2ubuntu7.2.

Debian 12 (Bookworm) :

sudo apt update && sudo apt upgrade
sudo apt install --only-upgrade linux-image-amd64
sudo reboot

Le noyau corrigé est la version 6.1.170-1 via le dépôt security.

Debian 13 (Trixie) :

sudo apt update && sudo apt upgrade
sudo reboot

Noyau cible : 6.12.85-1 ou ultérieur.

AlmaLinux / Rocky Linux :

sudo dnf update kernel
sudo reboot

Vérifier que le patch est actif après reboot :

uname -r
grep -qE '^algif_aead ' /proc/modules && echo "EXPOSE" || echo "OK : module absent"

Sous le capot : comment fonctionne l'exploit

Sans rentrer dans un niveau de détail qui n’a pas sa place ici, le principe de CopyFail mérite qu’on s’y arrête deux minutes.

L’exploit enchaîne deux sous-systèmes du noyau, l’interface cryptographique AF_ALG et l’appel système splice(), pour effectuer une écriture de 4 octets dans le page cache. Et ce qui rend la technique vraiment redoutable, c’est ça : pas de condition de course, pas d’offset spécifique au noyau. C’est fiable, répétable, et ça modifie le comportement d’un binaire setuid en mémoire sans toucher au fichier sur disque.

Conséquence directe : les contrôles d’intégrité classiques basés sur un hash ne voient rien. Le fichier sur disque est intact. C’est l’exécution qui est compromise. Et clairement, ça pique.

Ce que ça change dans mon approche

Aucun service cassé déclaré suite au workaround. Les machines tournent. Mais l’épisode laisse une trace, parce qu’il met le doigt sur un angle mort très courant : la veille qui existe, mais qui n’est pas actionnable.

La prochaine étape, c’est un alerting CVE ciblé par stack. Pas une newsletter générique qui balance 200 CVE par semaine. Un système qui sait ce que je fais tourner, et qui me secoue uniquement quand mon inventaire est directement concerné. C’est faisable, ce n’est pas si complexe à mettre en place, et ce mois d’avril me confirme que c’est nécessaire.

La vraie question que pose CopyFail

« Linux, c’est secure. »

On l’entend souvent. On le dit parfois soi-même, avec un petit sourire. Et globalement, oui : transparence du code, écosystème open source, réactivité sur les correctifs, tout ça est réel.

Mais CopyFail te rappelle un truc très simple : neuf ans. La faille était là depuis 2017. Pas introduite par un acteur malveillant, pas « cachée » volontairement. Juste planquée dans une optimisation anodine, invisible à l’œil humain pendant presque une décennie.

Et c’est une IA qui l’a trouvée.

Le signal de fond est là : avec la démocratisation des outils d’analyse de code assistés par IA, on va probablement voir davantage de failles de ce type remonter. Des vulnérabilités anciennes, enfouies dans des millions de lignes, que personne n’avait les moyens d’auditer à cette profondeur. Ce n’est pas une mauvaise nouvelle en soi. Mieux vaut les sortir au grand jour que se les prendre en pleine production. Mais ça veut dire une chose : la veille ne peut plus être une tâche passive.

Linux reste l’une des options les plus solides pour une infra maîtrisée. Mais « open source et auditable » ne veut pas dire « audité ». Et « secure by default » ne veut pas dire « secure forever ».

La prochaine fois que l’alerte passe dans le flux, je ne scrollerai pas.

Sources : copy.fail - Ubuntu Security Blog - CERT-EU Advisory 2026-005 - Live et veille : Yves Rougy