Connexion Premium

Dirty Frag : une faille de sécurité de 9 ans d’âge dans le noyau Linux

Le début d'une série ?

Dirty Frag : une faille de sécurité de 9 ans d’âge dans le noyau Linux

Illustration : Flock

Ce 7 mai, une nouvelle faille dans le noyau Linux permettant d’obtenir les droits superutilisateur a été divulguée. Mais l’embargo sur sa découverte a été cassé par des tiers. Même si un moyen de l’endiguer a été disponible rapidement, les responsables de distributions Linux courent depuis pour proposer à leurs utilisateurs un noyau incluant un patch.

Ce week-end du 8 mai a été bien actif pour les administrateurs systèmes : un peu plus d’une semaine après la révélation de la faille Copy fail dans le noyau Linux, une autre vulnérabilité a été rendue publique le 7 mai dernier. Elle est maintenant décrite sous le nom de Dirty Frag.

Comme pour Copy fail, en l’exploitant, la faille permet une escalade des privilèges, c’est-à-dire qu’un utilisateur lambda d’une machine peut très facilement accéder aux droits d’accès superutilisateur et faire ce que bon lui semble. Encore faut-il avoir un compte sur la machine.

Embargo cassé

Cette faille a été détectée par le chercheur indépendant Hyunwoo Kim. Mais celui-ci n’avait pas prévu de diffuser l’information si tôt. Comme il l’a expliqué vendredi sur la liste de discussion oss-security, d’autres personnes ont outrepassé l’embargo fixé sur la divulgation de cette faille qui concerne la plupart des distributions Linux.

Ainsi, vendredi, au moment où il a posté le message, aucun patch n’existait et aucun numéro de vulnérabilité ne lui avait été affecté. Le seul moyen qu’il proposait pour endiguer son exploitation était de bloquer les modules dans lesquels le problème se trouvait via la commande :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Depuis, la communauté s’est affairée à mettre tout en place pour bloquer la faille. Ainsi, Hyunwoo Kim a créé un dépôt GitHub officiel sur le sujet pour décrire et c’est en fait deux CVE qui ont été créées : CVE-2026-43284 puis CVE-2026-43500. Le score de vulnérabilité de la seconde n’est pas encore fixé mais celui de CVE-2026-43284 est de 8,8. Comme pour Copy Fail, le vecteur d’attaque est local (AV:L) : il faut déjà avoir un accès local sur la machine et le score aurait été sans doute plus élevé si ça n’avait pas été le cas.

Une modification possible depuis 2017

Les deux vulnérabilités se situaient aussi, comme avec Copy Fail, dans la possibilité de modifier le page cache (celui de xfrm-ESP depuis 2017 pour la CVE-2026-43284 et celui de RxRPC depuis 2023 pour la CVE-2026-43500). Corrigées respectivement depuis le 5 et 10 mai dans les deux projets, Hyunwoo Kim souligne qu’ « en d’autres termes, la durée de vie effective de ces vulnérabilités est d’environ 9 ans ».

La similarité avec Copy fail n’est pas étonnante puisque Hyunwoo Kim explique que c’est la première faille qui a inspiré sa recherche d’autres du même type

Le chercheur donne aussi un PoC. À Next, nous avons testé sur un serveur dédié virtuel chez OVHCloud sur lequel est installé Ubuntu 25.04. Nous avons pu reproduire le comportement, ainsi n’importe quelle personne qui a un compte sur la machine peut devenir root et y faire ce qu’elle veut.

Dans sa documentation, avant de pouvoir déployer le correctif de votre distribution, Hyunwoo Kim propose la même façon d’endiguer le problème que dans son message sur la liste oss-security.

Comme l’explique Ubuntu sur son blog, celle-ci peut poser des problèmes si on utilise le protocole de VPN IPSec comme le logiciel strongSwan. C’est aussi le cas si on se sert du système d’archivage distribué AFS (Andrew File System) « ou d’une autre application utilisant RxRPC ».

Course pour patcher

Petit à petit, les responsables des distributions Linux déploient un correctif. C’est le cas pour certaines versions de Debian, par exemple. Mais, à cause du non respect de l’embargo, le déploiement n’était pas prêt lorsque la faille a été rendue publique. Sur un dépôt GitHub titré « Copy Fail 2: Electric Boogaloo », d’autres personnes ont publié des informations sur la faille en marge du travail de Hyunwoo Kim tout en le créditant.

Celui-ci explique avoir contacté l’équipe de sécurité du noyau Linux le 30 avril avec un exploit montrant les possibilités d’utilisation de la faille et que le chercheur Kuan-Ting Chen a travaillé en parallèle sur le problème. Celui-ci a proposé un patch le 4 mai sur la liste netdev et il a été intégré à la branche netdev le 7 mai. Hyunwoo Kim a ensuite informé les responsables des distributions Linux sur la linux-distros et un embargo de cinq jours a été fixé. Mais celui-ci a donc été cassé par un tiers, ce qui a précipité la mise en place d’une solution. Comme avec Copy Fail, les administrateurs systèmes se sont donc retrouvés avec des informations partielles sur le problème au moment de la divulgation.

Commentaires (21)

votre avatar
Même mécanique que copyfail : un splice() qui permet de modifier des pages mémoire dans le cache. J'imagine bien tous les mainteneurs de tous les drivers implémentant splice() vérifier frénétiquement s'ils ne sont pas vulnérables...
votre avatar
on est d'accord que ça touche seulement les machines qui utilisent AFP ou l'IPsec?
votre avatar
Non, le module est chargeable dynamiquement « au besoin ».

Encore quelques failles comme ça et avec un peu de chance, le modèle de kernel monolithique avec 90% d’inutile dedans pour toi sera enfin remis en question…
votre avatar
je voie pas en quoi ça changerait qu'il soit modulaire dans le cas présent.
votre avatar
S’il n’est pas installé sur la machine, il a moins de chances d’être chargé…
votre avatar
Sur les distribution dérivées de Debian, la première stratégie avec la création d'espace de noms était celle utilisée.
votre avatar
Se poserait alors la question de savoir de quel(s) module(s) tu as besoin, et donc de comprendre chacun.
Tout le monde n'a pas vocation à devenir expert du noyau.
votre avatar
Ce problème là est réglé depuis longtemps, grâce à un mécanisme qui s’appelle les dépendances.

$ dpkg -l |grep "ii lib" |wc -l
2392

Je n’ai probablement pas la moindre idée de ce que fait la moitié de ces bibliothèques. Mais elles sont utiles à mon système, le mécanisme de dépendances fait que si elles sont installées, c’est qu’elles servent à un programme installé.

$ find -iname ".ko" |wc -l
4225

Ça fait deux fois plus. Et je n’ai pas non plus la moindre idée de ce que font au moins la moitié de ces modules. Par contre, il est certain que beaucoup de ces modules sont totalement inutiles sur mon système, qui n’aura jamais le matériel correspondant. Beaucoup pourraient faire l’objet de méta-paquets (comme on le fait déjà pour les firmwares par exemple).

C’était acceptable et accepté tant que ce n’était que de la place perdue. Maintenant que ça devient une source de problèmes, j’espère que les mentalités vont changer.
votre avatar
Bah non puisque la faille est dans un module, pas dans le monolithe.
Tu voulais peut-être dire : il faudrait un micro-noyau avec les drivers qui tournent en espace user.
votre avatar
On n’a même pas besoin d’aller jusque-là. Juste distribuer le kernel de manière moins monolithique, avec des sous-paquets. Ça pourrait même dans un premier temps se faire sans remettre en question le modèle de développement du kernel lui-même. Qu’un module noyau ait une faille est un évènement normal. Que tout le monde soit affecté, y compris les 95% d’utilisateurs pour qui ce module est inutile, c’est juste de la mauvaise ingénierie.
votre avatar
Oui, bien sûr, on va empaqueter chaque module dans un paquet, et l'utilisateur devra savoir quel paquet il doit installer en fonction de son matériel.

On va y perdre un peu en user friendlyness, hein. Pour les plus jeunes qui n'ont pas connu cette ère glorieuse, ça leur fera goûter ce qu'était l'utilisation de Linux avant que udev et modprobe existent, la douce époque où il fallait charger un par un les modules correspondant à ton matériel dans etc/modules. Personnellement, cette époque ne me manque pas.
votre avatar
Oui car, bien sûr, entre « tout dans un paquet » et « 4500 paquets séparés », il n’y a pas de juste milieu, c’est bien connu…
votre avatar
Ok, et donc les modules algif_aead, esp4, esp6 et rxrpc, tu les mets dans quels paquets ?
votre avatar
@white_tentacle
C'est donc bien un problème pour les distributions plutôt que pour le kernel, non ?
votre avatar
Les deux. À la base, les dev kernel vont te dire que « c’est modulaire, avec kconfig, ça gère correctement les dépendances et tu mets exactement ce que tu veux ». Ce qui est vrai, mais pas du tout adapté à une distrib généraliste. Soit tu livres tout, soit tu livres rien, mais les intermédiaires, c’est la merde. Du coup, les distribs sont allées à la simplicité : on met quasi tout en module et tout dans un unique paquet, c’est plus simple, ça permet en plus une meilleure compatibilité en cas de changement de matos et la seule conséquence négative c’était de la place occupée.

Sauf qu’en fait, l’autre conséquence négative, c’est de la surface d’attaque. Et autant la surface d’attaque sur des services utiles, elle est acceptable, sur des choses inutiles, c’est beaucoup plus discutable. Donc à mon humble avis, les choses vont évoluer de ce côté. Ça viendra probablement des distribs renforcées en premier, et peut-être que ça se propagera jusqu’au kernel. Si ce n’est pas à cette faille-ci, ce sera à une prochaine, on en trouve des pelletées en ce moment…
votre avatar
Le modèle du noyau n'a probablement aucun impact concernant la sévérité des attaques de sécurité.

Il y a en effet moyen sans doute de mieux gérer la diffusion des modules, mais dans le cadre de IPSec par exemple ça peut concerner de fait tout le monde car ce n'est pas lié à un matériel spécifique ni même à des usages très exotiques. Comme tout ce qui est réseau, cela risque d'être diffusé de manière globale car c'est délicat de définir "qui en a besoin ou pas".

Si on recentre la discussion sur le matériel, il y a déjà de tels enjeux pour les initramfs où de nombreux utilitaires comme dracut se base sur les modules chargés au moment de l'installation du nouveau noyau pour fournir les modules strictement nécessaires à l'initramfs. Mais ce n'est pas sans poser problèmes avec un matériel qui reste potentiellement modulaire en particulier pour des dispositifs comme le Wifi ou le Bluetooth avec des clés amovibles.

Il est possible de générer un paquet par module noyau (Yocto le fait déjà automatiquement), et il y a moyen certainement de coupler une installation automatique du paquet en fonction du matériel comme on peut le faire pour les imprimantes. Cependant, ça ajoute aussi des inconvénients. Je me souviens des déboires aussi avec Windows avec ce genre de modèle. Tu fais une conférence avec une télécommande infrarouge avec un dongle USB ? Faut prier qu'il trouve le pilote en live, il faut donc Internet et un peu de temps (et parfois, c'est long !). Ou plus chiant, tu veux le pilote Wifi mais tu n'as que le Wifi comme accès à Internet là où tu es... Des scénarios qu'on a déjà vécu et qui peuvent être aussi très embêtants.

Puis on peut se poser la question, la plupart des modules du noyau sont liés au matériel. Il reste peu probable qu'un module pour un matériel que ta machine n'a pas puisse avoir une faille de sécurité exploitable (car il ne pourra de toute façon pas se charger ou en mode dégradé qui limite les interactions possibles).

Tout est question de compromis, pour le pilote considéré ici, pas sûr que ton approche aurait changé grand chose, pour d'autres ça pourrait effectivement. Il y a aussi d'autres approches :


  • On fourni tous les modules mais un système de chargement ou de liste noire automatiquement généré pour éviter de charger certains modules inutiles dans ton dos ;

  • Un système de knobs (actuellement à l'étude) où en cas de faille identifiée les admins peuvent facilement faire fonctionner le noyau dans un mode dégradé qui évite la faille (en contre partie d'autres choses) le temps de corriger le noyau plus tard ;

  • On utilise plus de modules de sécurités tels que SELinux pour bloquer certaines interactions non souhaitables avec le noyau depuis un programme random, dont le chargement d'un module noyau ;

  • Etc.

votre avatar
Merci d’avoir pris le temps de détailler ta réponse.
Le modèle du noyau n'a probablement aucun impact concernant la sévérité des attaques de sécurité.
Pas tout à fait. Mon propos, c’est de dire que le modèle de noyau monolithique encourage l’installation de modules par défaut, alors que très peu de gens en ont besoin. AndrewFS (puisqu’il fait partie des nominés pour dirtyfrag) est un vieux machin qui doit être utilisé dans 10 universités grand max. C’est effectivement beaucoup plus discutable pour ipsec, qui sert à beaucoup plus de monde, mais même ça ça pourrait ne pas être livré en standard, mais en dépendances d’autres paquets type strongswan. algif_aead, c’est largement pire, dans tous les articles que j’ai lu personne n’a été capable de dire à quoi il sert vraiment.
il y a moyen certainement de coupler une installation automatique du paquet en fonction du matériel comme on peut le faire pour les imprimantes. Cependant, ça ajoute aussi des inconvénients.
Oui. Je suis conscient des inconvénients. Mon propos est de dire qu’on va vers une inversion : les inconvénients d’avoir le module installé pourraient, dans bien des cas, dépasser celui de ne pas les avoir.
Il y a aussi d'autres approches
Oui. Une dernière que tu n’as pas évoquée, et qui aurait ici été efficace, est de bloquer, à un instant T après le démarrage de la machine, le chargement de nouveaux modules. À l’époque où je jouais avec gentoo hardened, j’avais mis un truc comme ça en place, et de mémoire, le blocage est irréversible (nécessite redémarrage pour débloquer). C’était d’ailleurs très chiant à l’usage pour un pc multi-usage, par contre pour un serveur dont le rôle est bien défini et le matos ne change pas ça se conçoit bien.
votre avatar
Il suffit de compiler ton noyau : cd /usr/src/linux && make xconfig
Perso je fais des noyau monolithique avec la config exacte de chaque machine, le reste est disable.

Après c'est casse tête : t'as l'interrogatoire de xconfig, et comme l'as remarqué un autre tu perds complètement le côté simple et plug & play... des linux modernes
Nouveau matos:

  • le trouver dans la liste,

  • cocher sa case,

  • recompiler le noyau,

  • rebooter

votre avatar
Je fais ça aussi, et en vrai je n'ai pas besoin d'y toucher souvent. De nos jours sur un PC fixe tout est intégré à la carte mère et ne change donc jamais, avec le plus souvent pour seule carte d'extension une carte graphique où il n'y a que 2 fabricants et un driver unique par fabricant. Sur un portable, la question ne se pose même pas.

En plus pour une carte graphique aujourd'hui la majorité des fonctionnalités sont sous forme de logiciels liés au serveur graphique, qui s'installent et se mettent à jour sous forme de paquets et non dans le noyau qui n'a qu'un driver assurant juste la communication avec la carte et la gestion de la console texte avant démarrage du serveur graphique.

Pour tout ce qui est périphériques externes, ça repose habituellement sur des normes assez peu nombreuses (en grande majorité les classes USB) avec un driver générique par norme, on peut toutes les activer sans souci pour pouvoir brancher n'importe quoi. Et sur un serveur, à l'inverse on peut toutes les désactiver. Les systèmes de fichiers, pareil il y en a très peu de vraiment utilisés.

La mise à jour d'un noyau à l'autre se fait plutôt bien en récupérant la config actuelle disponible dans /proc/config.gz, en utilisant make oldconfig sur le nouveau noyau, et en répondant oui aux nouvelles fonctionnalités et non à tous les nouveaux drivers puisqu'ils ne nous concernent pas. Parfois, notamment s'il s'agit surtout de mises à jour de sécurité, il n'y a même pas de questions posées.

J'y touche un peu plus souvent pour rajouter une fonctionnalité nécessaire à un logiciel (par exemple Docker en demandait pas mal que je n'avais pas mises) que pour supporter un nouveau matériel. Mais ça reste rare et la distribution que j'utilise (Gentoo) me signale ce genre de manque à l'installation du paquet.

Après oui, je ne m'attends pas à ce que tout le monde le fasse, mais ceux qui pensent que le noyau est trop monolithique devraient s'y pencher, parce qu'en vrai, il ne l'a jamais été si on part des sources.
votre avatar
Pareil je suis gentoo la première config du noyau de zéro pique un peu quand même :D
après ça doit faire 20ans, et effectivement le seul gros changement pour ma part a été le passage 32bits => 64bits vers 2010 sinon c'est toujours la même install mise à jour en rolling release depuis. ~1x / an je jette un œil à la config du noyau pour arbitrer / nettoyer ce qui s'est ajouté depuis la dernière fois.
votre avatar
Pour info :

  • la CVE-2026-43284 a été corrigée le 8 mai vers midi pour les versions Linux 7.0.5, 6.18.28, 6.12.87, 6.6.138, 6.1.172, 5.15.206 et 5.10.255

  • la CVE-2026-43500 a été corrigée ce matin à 8h20 pour les version Linux 7.0.6 et 6.18.29