« Dirty Frag » (CVE-2026-43284) : la faille du noyau Linux qui transforme un accès en lecture en privilèges root

Un fichier en lecture seule doit rester en lecture seule. La faille « Dirty Frag » (CVE-2026-43284, CVE-2026-43500 et CVE-2026-46300) parvient néanmoins à amener le noyau Linux à modifier sa copie mise en cache.

Cette faille permet à un programme s'exécutant avec très peu de privilèges d'écrire dans des fichiers qu'il ne devrait pouvoir que lire, en modifiant la copie que le noyau conserve en mémoire. À partir de là, il peut réécrire un élément auquel le système fait confiance et s'octroyer ainsi un accès root. Dans les environnements de conteneurs, la même technique qui permet d'atteindre le noyau hôte peut également atteindre le noyau du nœud partagé par toutes les charges de travail.

Cette faille de sécurité est présente depuis des années dans le code réseau du noyau, ce qui explique qu'elle concerne la plupart des versions du noyau prises en charge et la quasi-totalité des distributions majeures. Linux a corrigé cette faille et toutes les distributions ont rétroporté ce correctif ; celui-ci portera donc un numéro de version différent sur chacune d'entre elles.

Présentation de Dirty Frag

Red Hat regroupe trois CVE sous le nom de « Dirty Frag ». Elles se trouvent à différents endroits du code réseau du noyau, et l'une d'entre elles est une variante plus récente qui n'avait pas été prise en compte dans la première série de correctifs. Voici un comparatif de ces trois vulnérabilités.

Le sous-système vous indique si cela vous concerne. Si vous n'utilisez pas de VPN IPsec ni l'AFS, cela vous donne une idée rapide de l'importance à y accorder. C'est le module que vous devrez vérifier (lsmod | grep -E 'esp4|esp6|rxrpc') pour voir ce qui est chargé.

Linux conserve en mémoire les données des fichiers récemment consultés afin de ne pas avoir à les lire sur le disque à chaque fois. Cette copie en mémoire s'appelle le cache de pages. Certaines fonctions du noyau telles que splice() transmettre ces données mises en cache au code réseau sans les copier, mais en lui fournissant simplement un pointeur vers l'emplacement où elles se trouvent déjà. Cela permet de gagner du temps, à condition que chaque étape suivante sache que la mémoire est partagée et s'abstienne d'y écrire.

Le bogue est apparu à deux endroits distincts du code réseau du noyau. L'un concernait ESP, qui gère le trafic VPN chiffré. L'autre concernait 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 s'emparer d'un fichier en lecture seule susceptible de lui conférer des privilèges s'il était altéré, par exemple : /usr/bin/su, et d’injecter son contenu dans le chemin réseau afin que le déchiffrement défectueux finisse par écrire dans la mémoire de ce fichier. L’écriture aboutit dans le cache de page, qui est la copie du fichier que le système fournit à tout ce qui le lit. Le fichier sur le disque ne change jamais, mais la version en mémoire affiche désormais ce que l’attaquant lui a fait afficher. L’exécution de la commande « su » lit la copie altérée et accorde à l’attaquant un accès root, même s’il n’avait initialement que des droits de lecture sur ce fichier.

Fragnesia, référencée sous le numéro CVE-2026-46300, est la variante la plus récente. Le correctif « Dirty Frag » a amené le noyau à s'appuyer sur un marqueur indiquant : « ce fragment est partagé, effectuez une copie sécurisée avant de le modifier ». Mais un ancien bug datant de 2013, présent dans le code chargé de fusionner les fragments de paquets, supprime discrètement ce marqueur. Il est resté inoffensif pendant treize ans, car rien n'en dépendait. Malheureusement, le correctif « Dirty Frag » en dépendait, ce qui a transformé un bug dormant en une nouvelle faille permettant d'accéder aux privilèges root. 

Pourquoi le « Dirty Frag » est-il important pour les conteneurs ?

Tous les conteneurs partagent le même noyau que l'hôte ; ainsi, un conteneur piraté peut accéder au code vulnérable du noyau si ses droits de accès le permettent (appels système, espaces de noms, paramètres de politique de sécurité). Des chercheurs ont déjà publié des exploits de preuve de concept fonctionnels pour Kubernetes, et Ubuntu met clairement en garde contre le risque d'escape s de conteneurs. Si le conteneur parvient à accéder au noyau, le risque est un accès root sur l'ensemble du nœud.

Vous pouvez contrer certains aspects de l'attaque en exécutant les charges de travail sans droits root, en activant le profil seccomp « RuntimeDefault », en appliquant des politiques de pods restreintes et en limitant les espaces de noms des utilisateurs sans privilèges. Mais aucune de ces mesures ne corrige la faille elle-même. Seule la mise à jour du noyau fournie par le fournisseur permet d'y remédier.

Comment savoir si un hôte est exposé ?

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

Exécutez uname -r Pour connaître la version du noyau que vous utilisez, comparez-la à la version corrigée indiquée dans l'avis de sécurité de votre distribution. Ne la comparez pas au numéro fourni par le développeur en amont. La faille remonte à des noyaux datant d’environ 2017, et les distributions d’entreprise et LTS telles que RHEL, Ubuntu et Debian rétroportent le correctif sur l’ancienne version du noyau que vous utilisez déjà ; ainsi, un noyau corrigé peut toujours afficher une version datant de plusieurs années. Un hôte RHEL 8 entièrement corrigé affiche toujours la version 4.18, et cette version 4.18 contient le correctif. Vérifiez que la version du paquet corrigé correspond bien à celle indiquée par votre fournisseur.

lsmod | grep -E 'esp4|esp6|rxrpc' indique si le chemin de code vulnérable est chargé. Un résultat vide ne signifie pas pour autant que tout va bien, car ces modules se chargent à la demande. Et le fait qu'un module soit chargé ne signifie pas automatiquement qu'il soit dangereux. esp4, esp6 et rxrpc sont des modules courants qui sont parfaitement sûrs sur un noyau corrigé. Cela vous permet de connaître votre surface d'attaque et de déterminer s'il vaut la peine d'appliquer la mesure de protection consistant à les ajouter à la liste noire.

sysctl user.max_user_namespaces indique dans quelle mesure le chemin ESP est accessible. Une valeur supérieure à zéro signifie que les utilisateurs sans privilèges peuvent créer des espaces de noms, ce qui constitue la voie d'accès habituelle au chemin ESP. Une valeur égale à zéro bloque cette voie, mais uniquement pour l'ESP. Le chemin RxRPC ne nécessitant pas d'espaces de noms, cette mesure n'offre donc pas une protection totale.

Vérifiez la situation de votre fournisseur. Red Hat indique que la vulnérabilité CVE-2026-43500 n'affecte pas ses produits, tandis que les vulnérabilités CVE-2026-43284 et CVE-2026-46300 affectent les noyaux Red Hat Enterprise Linux pris en charge ainsi que toutes les solutions basées sur ceux-ci. Ubuntu publie la version exacte du paquet corrigé pour chaque branche de noyau qu'elle prend en charge.

Que faut-il surveiller ?

Le code de validation du concept est déjà accessible au public. Microsoft a signalé une activité limitée dans la vie réelle lorsqu'un attaquant élève ses privilèges à l'aide de su, même s'il convient de noter qu'il peut s'agir de « Dirty Frag » ou de son prédécesseur « Copy Fail », car il est difficile de les distinguer l'un de l'autre à partir des seuls journaux de processus.

Le moyen le plus réaliste de détecter cela réside dans les outils d’audit et d’EDR que vous utilisez déjà. Le framework d’audit de Linux permet d’enregistrer l’exécution des processus et les transitions setuid ; c’est là que la séquence révélatrice apparaîtrait : un binaire inconnu serait déposé et exécuté, suivi immédiatement par su. Surveillez le chargement des modules esp4, esp6 ou rxrpc lorsqu'il coïncide avec d'autres activités suspectes, en particulier sur un hôte qui n'a aucune raison d'utiliser IPsec ou AFS, ainsi que l'exécution de fichiers ELF récemment placés sur le système. 

Si vous soupçonnez une exploitation, effectuez vos contrôles d'intégrité depuis un environnement fiable plutôt que depuis l'hôte lui-même, qui pourrait être compromis. Et n'oubliez pas que le blocage des modules du noyau n'annule pas les modifications apportées au cache de pages par un attaquant.

La place d'Aikido

La plupart des analyses s'arrêtent au niveau de l'image ou du référentiel. Dirty Frag se trouve un niveau plus bas, dans le noyau à partir duquel le nœud démarre effectivement.

Aikido L'analyse de machines virtuelles de sécurité analyse les composants effectivement installés sur l'hôte en cours d'exécution à partir d'un instantané de l'cloud ; ainsi, un paquet de noyau vulnérable apparaît comme une vulnérabilité détectée sur l'hôte. Comme elle associe également les hôtes aux charges de travail et aux comptes qui y sont exécutés, vous pouvez évaluer l'ampleur des répercussions si un nœud venait à être compromis.

Pour les hôtes « cloud » connectés à Aikido, la commande analyse de machines virtuelles permet d’identifier ceux qui exécutent le paquet du noyau vulnérable et d’afficher les charges de travail qui y sont exécutées. La procédure de correction reste la même : appliquez le correctif au noyau du nœud et vérifiez la version chargée après le redémarrage.

{{cta}}

FAQ