Interview diffusée dans l'émission CPU release Ex0244 : THCon 10 ans.
[Interview enregistrée le 5 mai 2026 à la THCon]
Copy.fail est la dernière faille d'importance découverte dans le kernel Linux. Elle fait très mal : elle est présente depuis 10 ans et permet l'escalade de privilèges pour tous les utilisateurs présents sur le système. Affichant un score CVSS de 7.8/10, et un code Proof of Concept pesant 732 octets en Python. En clair, c'est un passe-partout dévastateur et universel.
Mais est-ce vraiment ça ? N'a-t-on pas exagéré son importance ? Découverte par l'analyseur IA Xint Code éditée par Theori en une heure de revue du code kernel, est-ce un coup marketing un peu trop bien monté pour se faire remarquer après deux années de CVE slop ?
Nous en parlons avec DXC://0, DevSecOps bi classé CTI
- Pour commencer, combien de fois êtes vous déjà venu à la THCon ?
- Quand j'ai vu l'info sur copy.fail passer au petit matin, je me suis dit
Woputain
, puis en relisantWoputain ! Woputain ! Woputain !
et là, on m'a dit que quand je monte à plus de 1 WPTPM (Woputain Par Minute), c'est que ça craint sérieux. Quelle fut votre première réaction ? - Faut-il paniquer si on a des équipements basés sur Linux et impatchable, ni shell root pour désactiver ?
- Le fait que le code fautif incriminé est dans le wrapper AEAD et le module
algif_aeaddu sous-système cryptographique suite à une optimisation un peu trop rapide, comme à une autre époque un patch malheureux de Debian donnant Heartbleed, doit-on considérer que la cryptographie devrait plus se conformer aux bonnes règles de gestion mémoire ? - Android est immunisé grâce à SELinux, d'autres qu'on peut facilement désactiver le module
algif_aeadvia le shell ou sinon invalider le cache antémémoire du système de fichier. A-t-on exagéré l'impact de copy.fail ? - Si les mises à jour kernel n'arrivent plus, que faire d'autre ?
- Xint Code a vraiment montré son utilité ?
- Il faut absolument mettre un ou plusieurs outils d'audit en IA avant de déployer en preprod ?
- Au risque de se faire noyer sous les fausses alertes ?
- On reproche aussi le timing au découvreur de la faille : 34 jours entre le moment où il divulgue la faille aux mainteneurs kernels et son annonce en public, sans attendre les paquets correctifs dans les distributions. Distribs qui ont appris la faille en même temps que leurs utilisateurs. Est-ce que la divulgation n'a pas été faite responsablement ou faut-il blâmer le temps de latence des distribs ?
- Faut-il interdire aux divulgateurs de failles de déposer les noms de domaine avant de décrire la faille ?
Interview : Da Scritch
Illustration : Makise Kurisu par Novadarkmadness, illustration fournie par le sujet, D.R.