Dirty Frag (CVE-2026-43284) : le bug du noyau Linux qui transforme un accès en lecture en accès root

Un fichier en lecture seule doit le rester. Dirty Frag (CVE-2026-43284, CVE-2026-43500 et CVE-2026-46300) pousse le noyau Linux à modifier malgré tout sa copie mise en cache.

Ce bug permet à un programme exécuté avec quasi aucun privilège d'écrire dans des fichiers auxquels il ne devrait avoir qu'un accès en lecture, en modifiant la copie conservée en mémoire par le noyau. À partir de là, il peut réécrire un élément de confiance du système et s'octroyer un accès root. Dans les environnements de conteneurs, la même astuce permettant d'atteindre le noyau de l'hôte peut atteindre le noyau du nœud partagé par l'ensemble des charges de travail.

Le modèle vulnérable est présent dans le code réseau du noyau depuis des années, ce qui explique pourquoi il affecte la plupart des versions de noyaux prises en charge ainsi que la quasi-totalité des distributions majeures. Linux a corrigé la faille et chaque distribution l'a rétroportée (backported), de sorte que le correctif portera un numéro de version différent sur chacune d'elles.

Vue d'ensemble de Dirty Frag

Red Hat regroupe trois CVE sous le nom de Dirty Frag. Celles-ci se situent dans différentes zones du code réseau du noyau, l'une d'elles étant une variante récente que la première série de correctifs n'avait pas corrigée. Voici comment elles se comparent.

Le sous-système vous indique si cela vous concerne. Si vous n'utilisez pas de VPN IPsec ou d'AFS, cela donne une indication rapide du niveau d'attention à y porter. Le module à vérifier est (lsmod | grep -E 'esp4|esp6|rxrpc) pour voir ce qui est chargé.

Linux conserve en mémoire les données de fichiers récemment consultées pour éviter d'avoir à lire sur le disque à chaque fois. Cette copie en mémoire est appelée le cache de pages. Certaines fonctions du noyau telles que splice() transmettre ces données en cache au code réseau sans les copier, en passant simplement un pointeur vers l'emplacement où se trouvent déjà les données. Cela économise des ressources, à condition que chaque étape ultérieure sache que la mémoire est partagée et n'y écrive pas.

Le bogue est apparu dans deux zones distinctes du code réseau du noyau. L'une concerne ESP, qui gère le trafic VPN chiffré. L'autre concerne RxRPC, un protocole plus ancien utilisé principalement par le système de fichiers AFS. Ni le chemin ESP ni le chemin RxRPC ne vérifient si la mémoire est partagée avant d'y écrire.

Cela permettait à un attaquant de prendre un fichier en lecture seule susceptible de lui conférer des privilèges en cas de modification, un peu comme /usr/bin/su, et d'injecter son contenu dans le chemin réseau afin que le déchiffrement erroné finisse par écrire dans la mémoire de ce fichier. L'écriture aboutit dans le cache de pages, c'est-à-dire la copie du fichier que le système sert à toute opération de lecture. Le fichier sur le disque ne change jamais, mais la version en mémoire reflète désormais ce que l'attaquant a voulu y inscrire. L'exécution de su lit la copie altérée et octroie à l'attaquant un accès root, alors même qu'il n'était autorisé qu'à lire ce fichier.

Fragnesia, répertoriée sous la référence CVE-2026-46300, est la variante la plus récente. Le correctif de Dirty Frag a incité le noyau à s'appuyer sur un marqueur indiquant que « ce fragment est partagé, créez une copie sécurisée avant de le manipuler ». Mais un vieux bogue datant de 2013, présent dans le code qui fusionne les fragments de paquets, supprime discrètement ce marqueur. Il est resté inoffensif pendant treize ans car rien ne s'en remettait. Malheureusement, le correctif de Dirty Frag en dépendait, transformant un bogue dormant en une nouvelle voie d'accès aux privilèges root. 

Pourquoi Dirty Frag représente-t-il un problème pour les conteneurs ?

Les conteneurs partagent tous un même noyau avec l'hôte ; par conséquent, un conteneur compromis peut atteindre le code vulnérable du noyau si ses autorisations le permettent (paramètres d'appel système, de namespace ou de politique de sécurité). Des chercheurs ont déjà publié des exploits fonctionnels de type proof-of-concept pour Kubernetes, et Ubuntu détaille le risque d'un container escape. Si le conteneur parvient à accéder au noyau, le risque est un accès root sur l'ensemble du nœud.

Vous pouvez atténuer une partie de l'attaque en exécutant les charges de travail avec des privilèges non-root, en activant le profil seccomp RuntimeDefault, en appliquant des politiques de pods restreintes et en limitant les namespaces utilisateur non privilégiés. Cependant, rien de tout cela ne corrige la faille sous-jacente. Seule une mise à jour du noyau fournie par l'éditeur permet d'y remédier.

Comment savoir si un hôte est exposé ?

Commencez par examiner l'hôte en cours d'exécution, et non le Dockerfile. Trois commandes peuvent vous y aider.

Exécutez uname -r pour identifier la version du noyau que vous utilisez, puis comparez-la à la version corrigée indiquée dans le bulletin de sécurité de votre distribution. Ne la comparez pas au numéro de version en amont (upstream). Le schéma vulnérable remonte à des noyaux datant d'environ 2017, et les distributions d'entreprise et LTS telles que RHEL, Ubuntu et Debian rétroportent (backport) le correctif sur la version de noyau plus ancienne que vous utilisez déjà. Par conséquent, un noyau corrigé peut tout de même afficher une version datant de plusieurs années. Un hôte RHEL 8 entièrement mis à jour affiche toujours la version 4.18, mais cette version 4.18 intègre le correctif. Vérifiez par rapport au numéro de paquet corrigé fourni par votre éditeur.

lsmod | grep -E 'esp4|esp6|rxrpc permet de vérifier si le chemin de code vulnérable est chargé. Un résultat vide ne garantit pas une sécurité totale, ces modules se chargeant à la demande. De même, un module chargé n'est pas nécessairement synonyme de danger. esp4, esp6 et rxrpc sont des modules ordinaires qui s'avèrent parfaitement sûrs sur un noyau corrigé. Cela vous permet d'évaluer votre surface d'attaque et de déterminer si l'atténuation par liste noire (blacklist) mérite d'être appliquée.

sysctl user.max_user_namespaces indique le niveau d'accessibilité du chemin ESP. Une valeur supérieure à zéro signifie que les utilisateurs non privilégiés peuvent créer des namespaces, ce qui constitue la voie d'accès habituelle au chemin ESP. Une valeur nulle ferme cette porte, mais uniquement pour ESP. Le chemin RxRPC ne requiert pas de namespaces, la protection n'est donc pas totale.

Vérifiez le statut auprès de votre éditeur. Red Hat indique que la faille CVE-2026-43500 n'affecte pas ses produits, tandis que les failles CVE-2026-43284 et CVE-2026-46300 touchent les noyaux Red Hat Enterprise Linux pris en charge ainsi que tous les systèmes basés sur ceux-ci. Ubuntu publie la version exacte du paquet corrigé pour chaque branche de noyau qu'il prend en charge.

Que devez-vous surveiller ?

Du code de type proof-of-concept est déjà disponible publiquement. Microsoft a signalé une activité limitée dans des environnements réels où un attaquant élève ses privilèges à l'aide de su, bien que l'entreprise prenne soin de préciser qu'il pourrait s'agir de Dirty Frag ou de son prédécesseur Copy Fail, les deux étant difficiles à différencier sur la seule base des journaux (logs) de processus.

Le moyen le plus réaliste de détecter cette menace repose sur les outils d'audit et d'EDR que vous utilisez déjà. Le framework d'audit de Linux permet de consigner l'exécution des processus et les transitions setuid, ce qui correspond au moment où la séquence caractéristique apparaîtrerait : un binaire inconnu est déposé et exécuté, suivi immédiatement par su. Soyez attentif au chargement des modules esp4, esp6 ou rxrpc en même temps que d'autres activités suspectes, en particulier sur un hôte qui n'a aucune raison d'utiliser IPsec ou AFS, ainsi qu'à l'exécution de fichiers ELF fraîchement déposés. 

Si vous soupçonnez une exploitation, exécutez vos vérifications d'intégrité depuis un environnement de confiance plutôt que depuis l'hôte potentiellement compromis lui-même. Et n'oubliez pas que le blocage des modules du noyau n'annule pas les modifications du cache de pages déjà effectuées par un attaquant.

Où se positionne Aikido

La plupart des analyses s'arrêtent à l'image ou au dépôt. Dirty Frag se situe une couche plus bas, dans le noyau effectivement amorcé par le nœud.

L'analyse de machines virtuelles d'Aikido Security lit ce qui est réellement installé sur l'hôte en cours d'exécution à partir d'un instantané du cloud, de sorte qu'un paquet de noyau vulnérable apparaît comme une anomalie au niveau de l'hôte. Comme elle relie également les hôtes aux charges de travail et aux comptes qui y sont exécutés, vous pouvez visualiser l'étendue des dégâts si un nœud est compromis.

Pour les hôtes cloud connectés à Aikido, l'analyse de machines virtuelles met en évidence ceux qui portent le paquet de noyau vulnérable et indique quelles charges de travail y sont exécutées. La correction reste la même : appliquez un correctif au noyau du nœud et confirmez la version chargée après le redémarrage.

{{cta}}

FAQ