Dirty Frag : la nouvelle faille Linux qui donne root en local

Dirty Frag est une nouvelle faille Linux publiee le 7 mai 2026 par le chercheur Hyunwoo Kim, aussi connu sous le pseudo @v4bel.

Petite correction avant de commencer : le nom est Dirty Frag, pas Dirty Flag. Le “frag” fait reference aux fragments de paquets reseau dans le noyau Linux, plus precisement au champ frag de struct sk_buff.

Sur le papier, Dirty Frag est une elevation locale de privileges. En clair : il faut deja pouvoir executer du code sur la machine. Mais une fois ce premier acces obtenu, la faille peut permettre de devenir root.

C’est exactement le genre de bug qui compte beaucoup sur des serveurs multi-utilisateurs, des environnements CI/CD, des machines de developpement, des VPS, des clusters Kubernetes ou des plateformes qui lancent du code tiers.

En bref

#

Les points a retenir :

• Dirty Frag est une classe de vulnerabilites du noyau Linux.
• Elle permet de modifier en memoire le page cache de fichiers normalement accessibles seulement en lecture.
• Elle chaine deux chemins vulnerables : xfrm/ESP et RxRPC.
• La premiere partie est suivie sous CVE-2026-43284.
• La seconde est suivie sous CVE-2026-43500, reservee au moment des echanges publics.
• Un exploit public existe.
• La faille est locale, mais elle peut donner un shell root.
• La mitigation temporaire consiste a desactiver les modules esp4, esp6 et rxrpc si vous n’en avez pas besoin.
• Les correctifs doivent venir des noyaux fournis par votre distribution.

Au moment ou j’ecris cet article, le 8 mai 2026, la situation bouge vite. Il faut donc verifier les bulletins de securite de sa distribution avant toute decision de production.

Pourquoi cette faille est dangereuse

#

Dirty Frag touche une zone sensible du noyau : la frontiere entre les donnees lues depuis le disque, le cache memoire, les paquets reseau et certaines operations cryptographiques.

Normalement, si un utilisateur peut seulement lire un fichier, il ne doit pas pouvoir le modifier. C’est la base des permissions Unix.

Mais le noyau garde souvent en memoire une copie des fichiers lus recemment : c’est le page cache. Quand un programme relit le meme fichier, Linux peut servir la copie en RAM au lieu de retourner immediatement sur le disque.

Dirty Frag exploite une erreur logique : dans certains chemins reseau, une page issue de ce cache peut etre referencee comme fragment de paquet, puis modifiee par une operation cryptographique realisee sur place.

Le fichier sur disque ne change pas forcement. Mais la copie en memoire, elle, peut etre modifiee. Et si un programme sensible consomme ensuite cette copie modifiee, l’attaquant peut obtenir un comportement totalement different de ce que les permissions devraient autoriser.

C’est la meme famille d’idees que Dirty Pipe et Copy Fail : on ne “pirate” pas directement les permissions du fichier, on trompe le noyau dans sa gestion des pages memoire.

Dirty Frag, Dirty Pipe, Copy Fail : meme famille, chemins differents

#

Dirty Frag arrive juste apres Copy Fail, et la comparaison avec Dirty Pipe revient partout. Elle est utile, a condition de ne pas tout melanger.

Le point commun est toujours le meme : une donnee que l’utilisateur ne devrait pas pouvoir modifier finit par etre modifiee en memoire, parce qu’un chemin du noyau suppose a tort qu’il travaille sur une copie privee.

La difference, c’est le chemin d’acces. Dirty Frag passe par les fragments de paquets reseau (skb frags) et par des operations cryptographiques in-place, ce qui le rend moins intuitif qu’un bug de permissions classique.

Le mecanisme en une image mentale

#

Pour comprendre Dirty Frag sans lire tout le code du noyau, on peut resumer le flux comme ca :

fichier lisible
    -> page cache
        -> splice / zero-copy
            -> fragment de paquet reseau
                -> crypto in-place dans le noyau
                    -> ecriture dans la page du cache
                        -> programme privilegie relit la version modifiee

Ce schema simplifie beaucoup, mais il donne l’intuition importante : le probleme n’est pas que l’attaquant obtient soudain un droit d’ecriture sur le fichier. Le probleme est qu’il arrive a faire ecrire le noyau lui-meme dans une page memoire qui represente ce fichier.

Les deux pieces de Dirty Frag

#

Dirty Frag n’est pas une seule faille isolee. Le write-up public de Hyunwoo Kim decrit deux vulnerabilites qui se completent.

xfrm/ESP Page-Cache Write

#

La premiere variante concerne xfrm/ESP, utilise notamment par IPsec.

Dans certains cas, le noyau traite un paquet non lineaire contenant un fragment partage sans effectuer la copie de protection attendue. Ensuite, une operation cryptographique in-place peut ecrire quelques octets dans le fragment.

Le probleme est que ce fragment peut pointer vers une page du page cache, preparee par l’attaquant via des mecanismes zero-copy comme splice().

Cette variante est puissante, car elle donne une primitive d’ecriture relativement controlable. D’apres le write-up, elle peut servir a modifier en memoire /usr/bin/su afin d’obtenir une execution avec les privileges root.

Mais elle a une contrainte : elle depend de la possibilite de creer certains namespaces et d’enregistrer des etats XFRM. Sur des distributions ou la creation de user namespaces est restreinte, cette voie peut etre bloquee.

RxRPC Page-Cache Write

#

La seconde variante concerne RxRPC, un protocole lie historiquement a AFS.

Ici aussi, le probleme vient d’une operation cryptographique in-place sur des donnees qui peuvent pointer vers une page du page cache. La primitive est moins directe que dans le cas xfrm/ESP, mais elle ne depend pas des memes permissions.

Dans le scenario public, cette variante permet de viser /etc/passwd en memoire pour provoquer une authentification root sans mot de passe dans certaines conditions.

C’est la que Dirty Frag devient particulierement interessant pour un attaquant : si la voie xfrm/ESP est bloquee par une politique locale, la voie RxRPC peut encore fonctionner sur certains systemes. Et inversement, si RxRPC n’est pas present, xfrm/ESP peut suffire.

Pourquoi le chainage compte

#

Une faille locale avec beaucoup de preconditions reste souvent limitee. Une faille locale avec deux chemins independants devient beaucoup plus serieuse.

Le chercheur resume l’idee ainsi :

• xfrm/ESP est present dans beaucoup de distributions, mais peut etre bloque si la creation de user namespaces est interdite ;
• RxRPC ne depend pas du meme privilege, mais le module n’est pas disponible ou charge partout ;
• les deux chemins couvrent donc les angles morts l’un de l’autre.

Ce n’est pas magique : toutes les machines Linux ne sont pas exploitables de la meme facon dans toutes les configurations. Mais la combinaison donne une surface beaucoup plus large qu’un bug kernel tres specialise.

Versions et distributions concernees

#

Le depot Dirty Frag indique que la variante xfrm/ESP remonte a un changement de janvier 2017, tandis que la variante RxRPC remonte a juin 2023.

Le chercheur mentionne des tests sur plusieurs distributions majeures, dont Ubuntu, RHEL, openSUSE Tumbleweed, CentOS Stream, AlmaLinux et Fedora.

Canonical confirme aussi que les vulnerabilites affectent les modules noyau lies a ESP/IPsec et RxRPC, et que les versions Ubuntu listees dans son billet sont affectees tant qu’un noyau corrige n’est pas installe ou qu’une mitigation n’est pas appliquee.

Canonical evalue la severite a High, avec un score CVSS 3.1 de 7.8, en attendant les scores officiels CVE/NVD.

Statut des CVE et des correctifs

#

La situation a evolue tres rapidement entre le 7 et le 8 mai 2026.

Sur oss-security, Greg Kroah-Hartman indique que :

• CVE-2026-43284 est assignee a la premiere faille ;
• cette premiere faille est corrigee dans les dernieres mises a jour stables du noyau ;
• CVE-2026-43500 est reservee pour la seconde faille ;
• la seconde n’etait pas encore corrigee dans une version de noyau publiee au moment de son message.

Le depot Dirty Frag mentionne aussi un correctif upstream autour du commit f4c50a4034e6, lie a la voie xfrm/ESP.

La conclusion pratique est simple : ne vous contentez pas de savoir qu’un patch existe upstream. Sur un serveur, ce qui compte est le noyau effectivement fourni par Debian, Ubuntu, Red Hat, SUSE, AlmaLinux, Fedora, votre fournisseur cloud ou votre distribution specialisee.

Que verifier sur ses serveurs

#

Premiere verification : savoir si les modules concernes sont charges.

grep -E '^(esp4|esp6|rxrpc) ' /proc/modules

Si cette commande retourne des lignes, au moins un des modules concernes est charge.

On peut aussi regarder la version du noyau :

uname -a

Puis verifier les bulletins de securite de sa distribution. C’est le point le plus important, parce qu’un numero de version upstream ne suffit pas toujours : les distributions backportent souvent des correctifs sans changer radicalement la version affichee du noyau.

Reponse rapide pour admin presse

#

Si vous avez peu de temps, je traiterais le sujet dans cet ordre :

uname -a
grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || true

Puis :

1. verifier si la machine utilise IPsec, StrongSwan, AFS ou RxRPC ;
2. lire le bulletin de securite de la distribution ;
3. appliquer la mitigation si les modules ne sont pas necessaires ;
4. installer le noyau corrige des qu’il est disponible ;
5. redemarrer, car un noyau corrige non demarre ne protege pas la machine ;
6. verifier apres reboot que le noyau attendu tourne bien.

Apres redemarrage :

uname -a
grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || echo "Modules non charges"

Je ne lancerais pas le PoC public sur une machine de production pour “voir si ca marche”. Sur ce type de faille, le test peut contaminer le page cache et laisser la machine dans un etat bizarre jusqu’a vidage du cache ou redemarrage.

Mitigation temporaire

#

La mitigation recommandee publiquement consiste a empecher le chargement des modules concernes, puis a les decharger si possible.

Sur Ubuntu, Canonical recommande de creer un fichier /etc/modprobe.d/dirty-frag.conf contenant :

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

Puis de regenerer l’initramfs :

sudo update-initramfs -u -k all

Et de tenter de decharger les modules :

sudo rmmod esp4 esp6 rxrpc 2>/dev/null

Enfin, on verifie :

grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Modules encore charges" || echo "Modules non charges"

Si les modules restent charges, un redemarrage peut etre necessaire.

Attention : cette mitigation peut casser des usages legitimes.

Elle peut notamment impacter :

• des VPN IPsec ;
• des configurations StrongSwan ;
• des usages d’ESP ;
• AFS ;
• des applications qui dependent de RxRPC.

Sur un serveur qui utilise IPsec en production, il ne faut pas appliquer ca a l’aveugle au milieu de la journee. Sur un VPS qui n’utilise ni IPsec ni AFS, la mitigation est beaucoup moins risquee.

Et les conteneurs ?

#

Dirty Frag est d’abord une faille locale du noyau. Dans un environnement conteneurise, le noyau reste partage entre l’hote et les conteneurs.

C’est pour cela que ce type de bug est toujours sensible dans Kubernetes, Docker, containerd ou les plateformes CI qui executent du code non fiable.

Canonical indique que, dans des deploiements executant des workloads tiers arbitraires, Dirty Frag peut faciliter des scenarios d’evasion de conteneur, meme si un proof-of-concept public d’evasion de conteneur n’etait pas cite dans son billet.

En pratique, je regarderais en priorite :

• les runners CI auto-heberges ;
• les clusters qui executent du code utilisateur ;
• les plateformes PaaS internes ;
• les noeuds Kubernetes exposes a des workloads tiers ;
• les machines de build ;
• les serveurs de lab ou plusieurs personnes ont un acces shell.

Detection : que peut-on voir ?

#

Dirty Frag ne modifie pas necessairement le fichier sur disque. C’est justement ce qui complique la detection.

Un controle d’integrite classique sur disque peut ne rien voir si seule la page en memoire a ete alteree. Apres redemarrage ou vidage du page cache, la modification peut disparaitre.

Quelques signaux a surveiller :

• execution inattendue de su ;
• shells root obtenus depuis des comptes non privilegies ;
• appels suspects a unshare, splice, vmsplice, socket(AF_RXRPC) ou XFRM ;
• chargement inhabituel des modules esp4, esp6 ou rxrpc ;
• activite anormale autour de /etc/passwd ou /usr/bin/su ;
• processus de compilation ou execution d’un PoC public.

Ce ne sont pas des indicateurs parfaits. Ils servent surtout a orienter une investigation.

Ce que je ferais maintenant

#

Pour un serveur personnel ou un homelab :

1. Verifier si esp4, esp6 ou rxrpc sont charges.
2. Lire le bulletin de securite de la distribution.
3. Appliquer la mitigation si ces modules ne servent pas.
4. Mettre a jour le noyau des qu’un correctif distribution est disponible.
5. Redemarrer si necessaire.
6. Surveiller les logs et les acces locaux recents.

Pour une infrastructure de production :

1. Inventorier les noyaux et distributions.
2. Identifier les machines avec utilisateurs locaux ou workloads tiers.
3. Identifier les dependances IPsec, StrongSwan, AFS ou RxRPC.
4. Tester la mitigation sur un noeud non critique.
5. Deployer la mitigation la ou elle ne casse rien.
6. Planifier les mises a jour noyau.
7. Redemarrer les machines qui en ont besoin.
8. Garder une trace des exceptions.

Le piege serait de traiter Dirty Frag comme une simple news securite. C’est une faille locale, oui. Mais les failles locales sont exactement ce qui transforme un petit acces initial en compromission complete.

Mon avis

#

Dirty Frag est interessante parce qu’elle montre encore une fois que les bugs les plus dangereux du noyau ne sont pas toujours des corruptions memoire spectaculaires.

Ici, le probleme est logique : une page qui aurait du etre copiee ou isolee se retrouve modifiee au mauvais endroit. Le noyau fait une operation plausible, mais dans un contexte ou l’hypothese de depart est fausse.

C’est sobre, technique, et tres efficace.

Pour les admins, la reponse doit etre tout aussi sobre :

• verifier l’exposition ;
• mitiger si possible ;
• suivre les avis distribution ;
• patcher le noyau ;
• redemarrer proprement ;
• ne pas oublier les machines de build et les environnements de test.

Dirty Frag ne veut pas dire que tout Linux est perdu. Mais ca veut dire qu’il faut traiter les machines multi-utilisateurs et les environnements a code tiers avec serieux, surtout tant que tous les correctifs ne sont pas arrives dans les distributions.

Sources verifiees

#

Sources consultees le 8 mai 2026 :

• Depot GitHub V4bel/dirtyfrag
• Write-up technique Dirty Frag
• Image Tux utilisee comme visuel de l’article
• Publication initiale sur oss-security
• Mise a jour CVE par Greg Kroah-Hartman sur oss-security
• Mitigations Ubuntu / Canonical
• Contexte sur la publication anticipee et le n-day