Dirty Frag : deux nouvelles vulnérabilités du noyau Linux divulguées publiquement

Vous avez aimé la saga Copy Fail ? Vous allez adorer la suite : Dirty Frag !

Dirty Frag est le nom donné à une nouvelle classe de vulnérabilités du noyau Linux, découverte et signalée par Hyunwoo Kim (@v4bel). Elle regroupe deux failles distinctes : xfrm-ESP Page-Cache Write et RxRPC Page-Cache Write, qui permettent toutes deux à un utilisateur local non privilégié d’obtenir les droits root sur la quasi-totalité des distributions Linux modernes. Ces deux failles ont été divulguées publiquement le 7 mai 2026, après qu’un tiers a publié un exploit sur Internet avant la fin de l’embargo.

De quoi s’agit-il ?

Dirty Frag appartient à la même famille que Dirty Pipe et Copy Fail (CVE-2026-31431). Le point commun (outre la divulgation la veille d’un jour férié): via l’appel système splice(), un attaquant peut pousser une page du cache de fichiers (par exemple /etc/passwd ou /usr/bin/su) dans le flux réseau côté envoi. Le noyau effectue alors une opération cryptographique directement sur cette page en mémoire vive, la modifiant à l’insu du système de fichiers. Le fichier sur disque reste intact, ce qui rend la corruption invisible aux outils de vérification d’intégrité classiques.

Les vulnérabilités sont cataloguées sous cve :

• CVE-2026-43284
• CVE-2026-43500

Variante 1 : via IPsec ESP

Une optimisation de performance dans le code IPsec du noyau omet de copier les données dans un tampon privé avant de les déchiffrer, lorsque le paquet réseau contient un fragment mais pas de liste de fragments. Si ce fragment pointe vers une page du cache de fichiers insérée par splice(), le déchiffrement se produit directement sur cette page.

L’exploit peut ainsi écrire 4 octets arbitraires à n’importe quel offset d’un fichier en cache. En répétant l’opération 48 fois, il remplace les 192 premiers octets de /usr/bin/su en mémoire par un mini-exécutable qui ouvre un shell root. L’opération est déterministe, sans race condition, et un simple su depuis n’importe quel terminal suffit à déclencher l’escalade.

Cette variante nécessite de pouvoir créer un espace de noms utilisateur isolé, une capacité parfois bloquée sur Ubuntu par la politique AppArmor. Le bug est présent dans le noyau depuis janvier 2017, soit près de neuf ans d’exposition silencieuse.

Variante 2 : via RxRPC (AFS)

Le même problème existe dans le code de vérification du protocole RxRPC (utilisé par le système de fichiers réseau AFS) : un déchiffrement en place est effectué sur les données du paquet sans vérifier si elles proviennent d’une page du cache de fichiers.

Ici, la valeur écrite n’est pas directement contrôlable : elle passe par une fonction de chiffrement, mais l’attaquant peut faire une recherche par force brute de la clé produisant les octets désirés. Pour une cible comme /etc/passwd, où seule une poignée d’octets doit être modifiée, cela prend quelques secondes au maximum.

L’exploit vide le champ mot de passe de l’entrée root dans /etc/passwd. Lorsque PAM est configuré pour accepter les mots de passe vides (nullok), un simple su - accorde ensuite le shell root sans demande de mot de passe.

Cette variante ne nécessite aucun privilège particulier et fonctionne sans espace de noms isolé. Elle requiert uniquement que le module rxrpc soit chargé (celui-ci s’autocharge dès qu’un socket AF_RXRPC est ouvert), ce qui est le cas sur Ubuntu par défaut, mais pas sur RHEL 10.1. Ce bug a été introduit en juin 2023.

Un exploit, toutes les distributions

Les deux variantes se complètent : l’une couvre les environnements où la création de name space est autorisée, l’autre les systèmes Ubuntu où elle est bloquée mais où rxrpc est disponible. Un seul binaire enchaîne les deux tentatives et couvre ainsi l’ensemble des distributions majeures.

Point important : Dirty Frag contourne la mitigation de Copy Fail

La mitigation largement recommandée pour Copy Fail consiste à désactiver le module algif_aead. Cette mesure ne protège pas contre Dirty Frag, qui ne dépend pas de algif_aead et peut être déclenché indépendamment de sa disponibilité. Les systèmes ayant appliqué uniquement cette mitigation restent pleinement vulnérables.

Chronologie de la divulgation

xfrm-ESP Page-Cache Write

RxRPC Page-Cache Write

Le patch RxRPC n’a pas encore été intégré dans l’arbre upstream au moment de la divulgation.

La rupture d’embargo par un tiers a contraint à une divulgation immédiate alors qu’aucune distribution n’avait encore intégré de correctif. Conséquence directe : aucune CVE n’a été réservée ni publiée avant divulgation. Il a fallu attendre le lendemain pour que les CVE soient attribuées, ce qui est exceptionnellement tardif et complique la gestion de la vulnérabilité pour les équipes de sécurité.

Que faire ?

Bien que le patch upstream pour la variante ESP ait été fusionné le 7 mai 2026, la rupture d’embargo a empêché les distributions d’intégrer le correctif à temps : aucune distribution ne propose de kernel corrigé à cette date. Le patch RxRPC n’est quant à lui pas encore fusionné upstream.

En attendant, des mitigations temporaires existent mais comportent des effets de bord significatifs selon l’environnement.

La mitigation officielle blackliste les modules esp4, esp6 et rxrpc, ce qui désactive IPsec ESP (IPv4 et IPv6) ainsi que RxRPC, ce dernier étant principalement utilisé par le système de fichiers distribué AFS. Si votre infrastructure ne repose pas sur ces protocoles, la mitigation est applicable sans impact fonctionnel. Dans le cas contraire, il faut attendre que votre distribution publie un noyau corrigé.

Consultez la section “Mitigation” du dépôt officiel pour la commande exacte.