DirtyFrag: une nouvelle faille Linux locale qui contourne la mitigation Copy Fail

Dans le cadre de notre veille sécurité, nous signalons DirtyFrag, une nouvelle classe de vulnérabilités Linux publiée par Hyunwoo Kim (@v4bel).

Le sujet est sérieux: DirtyFrag permet une élévation de privilèges locale vers root sur plusieurs distributions Linux majeures testées par l’auteur. La faille n’ouvre pas directement un accès distant, mais elle devient critique dès qu’un attaquant dispose déjà d’une exécution locale, même limitée.

Autre point important: DirtyFrag appartient à la même famille de problèmes que Dirty Pipe et Copy Fail. Elle vise elle aussi une modification du page cache, c’est-à-dire de données de fichiers vues en mémoire, mais sans nécessairement modifier immédiatement le fichier sur disque.

Pourquoi DirtyFrag est à traiter rapidement

DirtyFrag n’est pas une simple variante cosmétique de Copy Fail.

Le dépôt public explique que l’exploitation chaîne deux vulnérabilités:

• xfrm-ESP Page-Cache Write;
• RxRPC Page-Cache Write.

La première fournit une primitive d’écriture de 4 octets proche de Copy Fail, mais dépend de la capacité à créer un namespace. La seconde ne nécessite pas cette capacité, mais dépend du module rxrpc. En les chaînant, l’auteur cherche à couvrir les angles morts de chaque variante.

En pratique, cela donne une vulnérabilité locale difficile à ignorer:

• pas de race condition nécessaire;
• comportement présenté comme déterministe;
• élévation locale vers root;
• PoC public;
• correctifs distribution encore à suivre au moment de la publication du dépôt;
• mitigation Copy Fail insuffisante.

Pour une équipe d’exploitation, le point central est donc simple: si un utilisateur non privilégié ou un processus compromis peut exécuter du code sur l’hôte, DirtyFrag peut devenir une étape d’escalade.

Le lien avec Copy Fail

L’article sur Copy Fail expliquait déjà le risque lié aux écritures inattendues dans le page cache via des chemins noyau utilisant splice().

DirtyFrag reprend cette famille de bugs, mais déplace le problème vers le membre frag de struct sk_buff, une structure utilisée dans le chemin réseau du noyau Linux.

Dit plus simplement:

• un utilisateur non privilégié peut placer une page issue du cache fichier dans un chemin réseau via splice();
• certaines opérations noyau font ensuite du chiffrement ou du déchiffrement en place sur cette page;
• au lieu de travailler sur une copie privée, le noyau écrit sur une page liée au cache fichier;
• les lectures suivantes peuvent voir la version modifiée en mémoire.

C’est précisément ce type de confusion qui rend ces vulnérabilités dangereuses: le fichier semble légitime sur disque, mais sa représentation en mémoire peut être altérée.

Pourquoi la mitigation Copy Fail ne suffit pas

Pour Copy Fail, la mitigation temporaire publique consistait notamment à désactiver algif_aead.

DirtyFrag change la donne. Le dépôt indique explicitement que la chaîne DirtyFrag peut se déclencher même si algif_aead n’est pas disponible.

Cela signifie qu’un serveur sur lequel la mitigation Copy Fail a été appliquée ne doit pas être considéré comme protégé contre DirtyFrag. Il faut traiter DirtyFrag comme une alerte séparée, avec sa propre mitigation.

Les environnements les plus exposés

DirtyFrag est une vulnérabilité locale. Le risque est donc maximal sur les environnements où du code non totalement maîtrisé peut tourner sur les hôtes.

À prioriser:

• hôtes Linux multi-utilisateurs;
• serveurs de build et runners CI/CD;
• plateformes qui exécutent du code client ou utilisateur;
• environnements de conteneurs;
• bastions et machines d’administration partagées;
• serveurs déjà exposés à un risque de compromission applicative.

Sur un serveur applicatif classique, il ne faut pas lire DirtyFrag comme “n’importe qui sur Internet devient root”. La bonne lecture est plus opérationnelle: si une application vulnérable donne un shell limité, la séparation avec root peut devenir beaucoup plus fragile.

Mitigation immédiate DirtyFrag

Au moment de la publication du dépôt, les chercheurs indiquent qu’aucun correctif distribution n’est encore disponible et recommandent de bloquer les modules concernés, puis de vider le page cache.

La mitigation proposée consiste à empêcher le chargement de esp4, esp6 et rxrpc, à les décharger s’ils sont déjà actifs, puis à exécuter echo 3 > /proc/sys/vm/drop_caches.

Commande prête à copier/coller:

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"

Cette mitigation doit être appliquée avec prudence. esp4 et esp6 sont liés à IPsec/ESP, et rxrpc peut être utilisé par certains environnements spécifiques. Le vidage du page cache peut aussi provoquer une baisse temporaire de performance, le temps que le système relise depuis le disque les données qui étaient en cache. Avant déploiement massif, il faut donc vérifier les usages réels: VPN IPsec, tunnels, services internes, dépendances noyau particulières.

Correctif: mitigation d’abord, patch ensuite

La mitigation réduit l’exposition immédiate, mais elle ne remplace pas un correctif noyau.

Le write-up indique qu’un correctif pour la partie xfrm-ESP a été intégré dans l’arbre netdev le 7 mai 2026. Pour RxRPC, le document précise qu’un patch a été proposé, mais qu’il n’existait pas encore de correctif upstream au moment de la publication.

La bonne trajectoire opérationnelle est donc:

1. identifier les hôtes Linux concernés;
2. vérifier si les modules esp4, esp6 ou rxrpc sont chargés;
3. appliquer la mitigation, vidage du page cache inclus, sur les systèmes exposés si elle ne casse pas un usage légitime;
4. suivre les bulletins de vos distributions;
5. planifier le redémarrage sur noyau corrigé dès disponibilité;
6. vérifier post-intervention que les modules, services et dépendances attendus sont cohérents.

Comme toujours sur les failles noyau, la question n’est pas seulement “un patch existe-t-il ?”. Il faut vérifier s’il est packagé, installé et réellement chargé au redémarrage.

Ce que nous faisons dans ce type d’alerte

Chez Forget About IT, ce type de sujet entre directement dans le maintien en condition de sécurité d’une infrastructure Linux.

Une alerte comme DirtyFrag demande de croiser plusieurs éléments:

• version de noyau réellement en cours d’exécution;
• distribution et politique de backport;
• exposition locale possible;
• présence de workloads non fiables;
• usage éventuel d’IPsec/ESP ou RxRPC;
• capacité à appliquer une mitigation sans rupture;
• fenêtre de redémarrage pour charger un noyau corrigé.

C’est ce travail de qualification qui évite les réactions trop binaires. Ne rien faire serait dangereux. Appliquer une mitigation aveuglément sur des hôtes qui utilisent IPsec peut aussi créer un incident. La bonne réponse est rapide, mais elle reste maîtrisée.

Conclusion

DirtyFrag confirme que les vulnérabilités locales Linux doivent être suivies de près, surtout sur les environnements qui exécutent du code non totalement maîtrisé.

Le bon réflexe est clair:

• ne pas considérer la mitigation Copy Fail comme suffisante;
• bloquer esp4, esp6 et rxrpc si le contexte le permet;
• suivre les correctifs noyau de votre distribution;
• redémarrer sur un noyau corrigé dès que possible;
• prioriser les hôtes multi-utilisateurs, CI/CD, conteneurs et bastions.

Si vous avez besoin d’aide pour qualifier l’exposition ou organiser la mitigation sur vos serveurs Linux, nous pouvons vous accompagner dans le cadre de notre infogérance.

• Découvrir notre infogérance
• Nous contacter

Sources

• GitHub - V4bel/dirtyfrag
• GitHub - DirtyFrag technical write-up

FAQ: DirtyFrag et mitigation Linux

Qu’est-ce que DirtyFrag ?

DirtyFrag est une classe de vulnérabilités Linux locale d’élévation de privilèges qui chaîne deux problèmes de page cache: xfrm-ESP Page-Cache Write et RxRPC Page-Cache Write.

DirtyFrag a-t-elle une CVE ?

Au moment de la publication du dépôt par les chercheurs, aucune CVE n’était encore attribuée et aucun correctif distribution n’était annoncé comme disponible.

La mitigation Copy Fail suffit-elle contre DirtyFrag ?

Non. Les chercheurs indiquent que DirtyFrag peut être déclenchée même si le module algif_aead, ciblé par la mitigation Copy Fail publique, est désactivé.

Quelle mitigation appliquer en attendant les correctifs ?

La mitigation proposée consiste à bloquer le chargement des modules esp4, esp6 et rxrpc, à les décharger s’ils sont déjà actifs, puis à vider le page cache.

Faut-il patcher après la mitigation ?

Oui. La mitigation réduit l’exposition immédiate, mais la remédiation durable reste l’installation des correctifs noyau fournis par votre distribution.