Dirty Frag : root sur Linux via xfrm-ESP et RxRPC

Ce qui s'est passé

Le 7 mai 2026, deux vulnérabilités d'élévation de privilèges locaux ont été divulguées simultanément contre le noyau Linux, sous le nom collectif de Dirty Frag. La référence à Dirty Cow, célèbre LPE de 2016, est explicite : comme son aînée, Dirty Frag exploite des conditions de course autour de la gestion mémoire pour réécrire des structures critiques et obtenir des privilèges root depuis un compte utilisateur ordinaire. La différence majeure tient à la cible : là où Dirty Cow visait le gestionnaire de mémoire COW, Dirty Frag exploite le cache de pages associé à deux protocoles réseau peu connus mais activés par défaut sur la plupart des distributions.

La première faille, CVE-2026-43284, vise le sous-système xfrm-ESP, qui implémente le chiffrement IPsec ESP au niveau noyau. Le bug réside dans une écriture incorrecte vers le cache de pages lors du traitement de certains paquets ESP, ce qui permet à un attaquant local de corrompre la mémoire et de planter une exécution arbitraire. La seconde, CVE-2026-43500, frappe RxRPC, l'implémentation noyau du protocole utilisé par AFS et certains systèmes de fichiers distribués. Le pattern est similaire : une mauvaise gestion du cache de pages ouvre une fenêtre d'écriture en dehors des zones légitimes.

Prises individuellement, chacune des deux failles serait déjà critique. Combinées dans la chaîne Dirty Frag, elles donnent un exploit fiable dont la démonstration publique a fonctionné en quelques secondes sur des images vanilla des grandes distributions. Les chercheurs ont validé l'exploitation sur Ubuntu 24.04.4 LTS (très largement déployée en production), Red Hat Enterprise Linux 10.1, Fedora 44, openSUSE Tumbleweed, CentOS Stream 10 et AlmaLinux 10. La couverture est suffisamment large pour qu'on puisse considérer que l'écrasante majorité des serveurs Linux modernes sont vulnérables tant que les modules concernés sont chargés.

Côté chronologie, les chercheurs ont signalé les vulnérabilités aux mainteneurs du noyau Linux le 30 avril 2026, soit une semaine avant la divulgation publique. Cette fenêtre de coordination a permis aux principaux distributeurs de préparer des correctifs partiels, mais elle est restée trop courte pour livrer des patchs complets et testés sur l'ensemble des kernels supportés. Au moment de la publication, Ubuntu et Red Hat ont commencé à pousser des mises à jour pour CVE-2026-43284, mais CVE-2026-43500 reste sans correctif amont, ce qui force les administrateurs à s'appuyer sur des contournements.

La technique d'exploitation s'appuie sur des opérations légitimes du noyau, ce qui rend la détection difficile par signatures classiques. xfrm-ESP est utilisé dès qu'une politique IPsec est active, RxRPC est chargé sur certains hôtes par dépendance transitive, et dans les deux cas le chemin de code visé tourne avec les privilèges noyau. Les chercheurs ont publié un proof-of-concept open source qui prend la forme d'un binaire simple à compiler, ce qui élargit considérablement la surface d'attaque : tout adversaire ayant obtenu un shell utilisateur, par phishing, vol de credentials SSH, ou container escape, peut désormais escalader vers root en moins de cinq secondes.

Pour les exploitants, le vecteur le plus préoccupant est l'environnement multi-tenant. Sur un cluster Kubernetes partagé, sur une VM hôtant plusieurs locataires non privilégiés, ou sur une instance de jumphost avec de nombreux utilisateurs SSH, Dirty Frag permet à n'importe quel locataire de devenir administrateur de la machine hôte. Les fournisseurs cloud confirment que leurs propres images managées (Amazon Linux, Azure Linux, Google COS) intègrent les mêmes sous-systèmes vulnérables, même si leurs équipes ont déjà commencé à pousser des kernels patchés sur les contrôleurs de plan managé.

La mitigation officielle proposée par le chercheur consiste à désactiver les trois modules concernés via une commande modprobe blacklist appliquée aux modules esp4, esp6 et rxrpc, suivie d'un rmmod. Les distributions ont publié des advisories officiels (notamment Sophos, Ubuntu, Canonical, ainsi que des analyses techniques détaillées de Wiz, Tenable et Sysdig). Important : désactiver uniquement esp4 et esp6, ou uniquement rxrpc, laisse l'autre branche de la chaîne d'exploitation utilisable. Il faut bloquer l'ensemble des trois modules pour neutraliser totalement Dirty Frag.

Pour les administrateurs qui ne peuvent pas désactiver IPsec parce qu'ils l'utilisent en production (typiquement les VPN ipsec/strongSwan), le contournement consiste à attendre les patchs distributeurs spécifiques à xfrm-ESP, qui devraient arriver dans les jours suivant la divulgation. Côté détection, Sysdig et Wiz ont publié des règles eBPF et Falco qui surveillent les patterns d'écriture mémoire suspects sur les sous-systèmes incriminés.

Pourquoi c'est important

Dirty Frag arrive dans un contexte particulièrement sensible pour la sécurité du noyau Linux. Quelques semaines à peine après la divulgation de Copy Fail (CVE-2026-31431), une autre LPE largement exploitée et placée sous deadline CISA, la communauté découvre une nouvelle chaîne d'exploitation aux capacités similaires mais sur des sous-systèmes différents. Le rapprochement des deux découvertes suggère que des chercheurs offensifs concentrent leurs efforts sur les chemins de code peu audités du noyau, en particulier autour du cache de pages, et qu'on peut s'attendre à d'autres révélations dans les prochains mois.

Le mode opératoire choisi par les chercheurs, avec une divulgation responsable courte de sept jours et une publication immédiate du PoC, réouvre le débat sur les fenêtres de patch acceptables pour des vulnérabilités critiques du noyau. Sept jours suffisent pour un projet web qui pousse en continu, mais c'est très court pour le noyau Linux où les correctifs doivent être testés sur des centaines de variantes (LTS, mainline, distros downstream, kernels temps réel, kernels embarqués). Plusieurs voix dans la communauté kernel.org ont déjà demandé une coordination plus serrée entre chercheurs et mainteneurs, sans pour autant remettre en cause le principe de divulgation publique.

Pour les entreprises, l'enjeu est opérationnel et organisationnel. Patcher le noyau d'une flotte de serveurs Linux n'est jamais trivial : il faut redémarrer les machines (sauf à utiliser kpatch, livepatch ou kGraft, ce qui n'est pas universellement disponible), ce qui implique des fenêtres de maintenance, des plans de bascule applicative, et une coordination avec les équipes métiers. Les organisations qui n'ont pas industrialisé leur cycle de patching kernel vont perdre plusieurs jours, voire plusieurs semaines, avant d'avoir une flotte saine. Pendant ce temps, les attaquants disposent d'un PoC public et fonctionnel.

Sur le plan réglementaire, les entreprises soumises à NIS2 ou DORA doivent désormais documenter leur capacité à intégrer rapidement les correctifs sur les vulnérabilités critiques. Une LPE noyau de niveau Dirty Frag entre clairement dans la catégorie des incidents qui justifieraient une analyse de risque ad hoc et une mise à jour prioritaire des plans de continuité. Les autorités de contrôle, en cas d'incident exploitant ces CVE chez une entreprise régulée, seront enclines à demander pourquoi le délai de patch n'a pas été aligné sur le standard recommandé de 14 à 30 jours pour une criticité de ce niveau.

Ce qu'il faut retenir

• Dirty Frag combine CVE-2026-43284 (xfrm-ESP) et CVE-2026-43500 (RxRPC) pour donner root sur quasi toutes les distributions Linux modernes.
• Mitigation immédiate : désactiver les modules esp4, esp6 et rxrpc sur les hôtes qui n'utilisent pas IPsec ni AFS, en complément du patching du noyau dès qu'il est disponible.
• Priorisez les environnements multi-tenants et les jumphosts SSH, où l'impact d'une LPE est démultiplié par le nombre d'utilisateurs locaux.