Dirty Frag désigne deux vulnérabilités du noyau Linux publiées le 7 mai 2026 par Hyunwoo Kim. Elles sont suivies sous CVE-2026-43284 pour le chemin XFRM/ESP et CVE-2026-43500 pour RxRPC.
Dans les deux cas, un attaquant qui peut déjà exécuter du code localement peut modifier une page du cache mémoire associée à un fichier normalement accessible en lecture seule. Le démonstrateur public utilise cette primitive pour obtenir les privilèges root.
Mise à jour du 28 août 2026 : les deux CVE disposent désormais de correctifs dans les noyaux fournis par les principales distributions. La désactivation des modules reste une solution temporaire lorsque la mise à jour est impossible. L’article initial, écrit pendant la divulgation, indiquait encore que le second correctif n’était pas publié.
En bref#
- L’exploitation est locale : l’attaquant doit déjà pouvoir lancer du code sur l’hôte ou dans un workload partageant son noyau.
- Les deux chemins vulnérables concernent XFRM/ESP, utilisé par IPsec, et RxRPC, notamment utilisé par AFS.
- Un exploit local public existe. Canonical n’indique pas de démonstrateur public d’évasion de conteneur dans son avis.
- CVE-2026-43284 est évaluée à 8,8 et CVE-2026-43500 à 7,8, toutes deux au niveau High.
- La présence des modules dans
/proc/modulesaide à prioriser, mais ne suffit pas à prouver qu’un noyau est corrigé ou vulnérable. - La réponse recommandée est d’installer le noyau corrigé de la distribution, puis de redémarrer.
- La désactivation de
esp4,esp6etrxrpcpeut interrompre IPsec, StrongSwan ou AFS.
Explication technique#
Linux conserve en mémoire les pages de fichiers récemment lues. Ce page cache évite de relire les mêmes données sur le stockage à chaque accès.
Avec des mécanismes zero-copy comme splice(), une page peut aussi être référencée par un fragment de socket buffer, ou skb. Le problème apparaît lorsqu’un chemin réseau suppose que ce fragment lui appartient et effectue une opération cryptographique directement dessus. Si le fragment référence encore une page du cache, l’écriture modifie la copie en mémoire du fichier.
Le flux simplifié est le suivant :
fichier lisible
-> page cache
-> splice() et fragment de skb partagé
-> traitement cryptographique sur place
-> modification de la page en mémoire
-> relecture par un programme privilégiéLes permissions du fichier sur disque ne sont pas modifiées. C’est précisément ce qui rend le comportement difficile à repérer avec un simple contrôle d’intégrité du système de fichiers.
CVE-2026-43284 : XFRM/ESP#
Le premier chemin passe par XFRM et ESP, composants utilisés pour le traitement IPsec. Un fragment partagé pouvait atteindre une opération cryptographique sans la copie de protection attendue.
Le démonstrateur publié prépare une page du cache avec splice(), puis utilise cette primitive pour modifier en mémoire un binaire privilégié. L’exploitation dépend néanmoins des fonctions disponibles, des restrictions sur les espaces de noms utilisateur et de la configuration du noyau.
CVE-2026-43500 : RxRPC#
Le second chemin concerne RxRPC. Là encore, des fragments de page appartenant à un autre contexte pouvaient être traités directement par les opérations de sécurité du protocole.
Ce chemin n’a pas exactement les mêmes préconditions que XFRM/ESP. Désactiver seulement ESP ou seulement RxRPC laisse donc l’autre vulnérabilité potentiellement atteignable sur un noyau non corrigé.
Une famille plus large#
Des variantes supplémentaires ont été documentées après la divulgation initiale, notamment DirtyClone. Cela ne change pas l’action immédiate : il faut utiliser les paquets de sécurité de la distribution plutôt que sélectionner un correctif isolé à partir d’un unique commit amont.
Impact réel#
Serveur sans utilisateur local#
Le risque immédiat est plus faible si aucun compte non privilégié, agent de build ou service capable d’exécuter du code tiers n’est présent. La faille ne fournit pas, à elle seule, un accès distant initial.
Elle reste pertinente dans une chaîne d’attaque. Une compromission limitée d’une application peut fournir l’exécution locale nécessaire à l’élévation vers root.
Hébergement mutualisé et CI/CD#
Les machines multi-utilisateurs, runners CI auto-hébergés, services de compilation et plateformes qui exécutent du code non fiable sont prioritaires. L’attaquant y dispose plus facilement du premier niveau d’exécution requis.
Conteneurs et Kubernetes#
Les conteneurs partagent le noyau de l’hôte. Canonical considère qu’une exploitation peut faciliter une évasion de conteneur dans les environnements qui lancent des workloads arbitraires, même si son avis ne mentionne pas de démonstrateur public spécifique à ce scénario.
Un cluster qui n’exécute que des images maîtrisées reste moins exposé qu’une plateforme multi-tenant, mais il doit tout de même recevoir le noyau corrigé.
Vérifier son exposition#
Commencer par relever le noyau effectivement démarré :
uname -rSur Debian ou Ubuntu, lister les images installées :
dpkg-query -W -f='${Package}\t${Version}\n' 'linux-image-*' 2>/dev/nullLa comparaison doit se faire avec l’avis de la distribution. Un numéro de version amont ne suffit pas, car les correctifs sont régulièrement rétroportés sans changement majeur de version.
Vérifier ensuite les modules actuellement chargés :
grep -E '^(esp4|esp6|rxrpc) ' /proc/modules || echo "Modules non chargés"Ce résultat n’est qu’un indice. Un module absent de cette liste peut encore être disponible et chargé à la demande. La seule preuve de correction reste le statut du paquet publié par le fournisseur.
Exemples de versions Ubuntu corrigées#
Au 28 août 2026, Canonical publie notamment les versions suivantes :
| Version Ubuntu | Paquet noyau corrigé |
|---|---|
| 26.04 LTS | 7.0.0-22.22 |
| 25.10 | 6.17.0-35.35 |
| 24.04 LTS | 6.8.0-124.124 |
| 22.04 LTS | 5.15.0-181.191 |
| 20.04 LTS | 5.4.0-231.251 avec Ubuntu Pro |
Les noyaux HWE, cloud, temps réel et spécifiques aux fournisseurs ont leurs propres versions. Il faut consulter la ligne correspondant exactement au paquet installé.
Détection#
Il n’existe pas d’indicateur universel permettant d’affirmer qu’une exploitation a eu lieu. La modification peut ne toucher que le cache mémoire et disparaître après un redémarrage.
Les signaux suivants peuvent justifier une investigation :
- shell privilégié obtenu depuis un compte inattendu ;
- exécution d’un binaire de démonstration connu ;
- utilisation inhabituelle de
unshare,splice()ou de sockets RxRPC par un compte non privilégié ; - chargement inexpliqué de
esp4,esp6ourxrpc; - activité anormale autour de
/usr/bin/suou/etc/passwd.
Ces événements ne prouvent pas une exploitation. Inversement, leur absence ne prouve pas que la machine est saine. En cas de soupçon sérieux, isoler l’hôte et analyser sa mémoire et son historique d’exécution avant de le redémarrer.
Ne pas lancer le PoC sur un serveur de production pour tester l’exposition. Le test modifie volontairement le page cache et ne constitue pas une méthode de vérification sûre.
Correctifs et mitigations#
Installer le noyau de sécurité#
Sur Ubuntu, Canonical recommande la mise à jour des paquets, suivie d’un redémarrage :
sudo apt update
sudo apt full-upgrade
sudo rebootLe redémarrage interrompt les services et doit être planifié. Après le retour de la machine, vérifier le noyau réellement chargé :
uname -rSur Debian, RHEL, SUSE ou une distribution dérivée, utiliser l’avis et les paquets du fournisseur. Compiler uniquement le dernier noyau amont peut contourner les mécanismes de support et de rétroportage de la distribution.
Mitigation temporaire#
Si aucun noyau corrigé ne peut être installé immédiatement, les modules concernés peuvent être bloqués dans /etc/modprobe.d/dirty-frag.conf :
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/falseSur Ubuntu, la prise en compte au prochain démarrage nécessite de régénérer l’initramfs :
sudo update-initramfs -u -k allCette modification peut couper un VPN IPsec, StrongSwan, AFS ou une autre dépendance RxRPC. Elle doit être testée et accompagnée d’une procédure de retour arrière. Une fois le noyau corrigé installé, Canonical indique que cette mitigation n’est plus nécessaire.
Conclusion#
Dirty Frag est une élévation locale de privilèges, pas une compromission distante autonome. La priorité dépend donc de la capacité d’un utilisateur, d’un service ou d’un workload à exécuter du code sur l’hôte.
Les runners CI, environnements multi-utilisateurs et clusters exécutant du code tiers doivent être traités en premier. Pour les autres machines, la bonne réponse reste la même : vérifier l’avis du fournisseur, installer le noyau corrigé et confirmer après redémarrage que la version attendue est active.
Sources#
Sources vérifiées le 28 août 2026 :
- Canonical - Dirty Frag : impact, versions Ubuntu corrigées et mitigations
- Ubuntu Security - CVE-2026-43284
- Ubuntu Security - CVE-2026-43500
- Dépôt et write-up technique de Hyunwoo Kim
- oss-security - attribution initiale des CVE et état des correctifs
- oss-security - variante DirtyClone dans la famille Dirty Frag
