Comment Dirty Frag permet aux pirates d'obtenir un accès root sur les systèmes Linux

Vous cherchez des mesures d'atténuation ? Passez directement à la section suivante ↓

En bref

• Quoi : Une chaîne d'escalade de privilèges locaux sous Linux baptisée Dirty Frag, combinant CVE-2026-43284 (écriture dans le cache de pages xfrm-ESP) et CVE-2026-43500 (écriture dans le cache de pages RxRPC).
• Impact : Des exploits publics de validation de principe démontrent qu'il est possible d'obtenir de manière fiable une élévation des privilèges root à partir d'un compte local non privilégié sur des noyaux vulnérables.
• Situation : Des exploits publics fonctionnels circulent. L'embargo a été levé avant que l'application coordonnée des correctifs ne soit terminée.
• Gravité : Vecteur d'attaque local, faible complexité, aucune interaction de l'utilisateur, exploitation déterministe. CVSS : 7,8 (provisoire)
• Agissez dès maintenant :protégezimmédiatement les noyaux concernés. L'application de correctifs sans redémarrage permet de pallier la vulnérabilité « Dirty Frag » sans attendre les fenêtres de maintenance ni les redémarrages. Sinon, déployez les noyaux corrigés dès que possible. Si aucune de ces solutions n'est disponible dans l'immédiat, désactivez temporairement les chemins ESP et RxRPC vulnérables indiqués ci-dessous.

Suis-je concerné ?

Vous êtes probablement concerné si vous utilisez un noyau récent dérivé de la branche principale sur l'un des systèmes suivants :

• Ubuntu (versions LTS et versions actuelles)
• Red Hat Enterprise Linux, AlmaLinux, Rocky Linux, CentOS Stream
• Fedora
• openSUSE Tumbleweed
• La plupart des versions dérivées, y compris les variantes de CloudLinux

Vérification rapide des modules exposés :

lsmod | grep -E '^(esp4|esp6|rxrpc) '

Si l'un de ces éléments est chargé – ou peut être chargé automatiquement à la demande par un utilisateur sans privilèges –, vous devez considérer l'hôte comme vulnérable jusqu'à ce qu'il soit corrigé.

Vous êtes n'êtes pas automatiquement en sécurité simplement parce que vous avez postulé plus tôt Échec de la copie . Blocage algif_aead n'empêche pas les fragments sales.

Qu'est-ce que « Dirty Frag » ?

Dirty Frag est une chaîne d'escalade de privilèges au niveau du noyau (LPE) qui exploite deux voies de déchiffrement en ligne dans la pile réseau Linux :

• xfrm-ESP (esp4, esp6), utilisés par IPsec
• RxRPC (rxrpc), utilisé par AFS et le trafic RPC associé

Ce bogue appartient à la même famille que « Dirty Pipe » et « Copy Fail » : une routine du noyau écrit des données dans une page dont elle n'a pas l'exclusivité, ce qui finit par écraser le contenu d'une entrée du cache de pages correspondant à un fichier sur le disque.

La chaîne a été révélée par le chercheur Hyunwoo Kim. «Copy Fail 2 : Electric Boogaloo » constitue la partie xfrm-ESP de Dirty Frag (CVE-2026-43284), obtenue par rétro-ingénierie à partir du commit de correction public – il ne s'agit pas d'un CVE distinct ni de la chaîne complète.

Comment fonctionne réellement cette faille

Le cache de pages de Linux conserve en mémoire des copies du contenu des fichiers afin d'éviter que les lectures répétées ne nécessitent d'accéder au disque. Lorsque vous cat /etc/passwd, le noyau vous fournit presque toujours des octets provenant d'une page mise en cache plutôt que du système de fichiers. Cette page mise en cache est partagée : tous les lecteurs de ce fichier voient la même mémoire.

Prise en charge des chemins de réception du noyau moderne décryptage sans copie . Lorsque des données réseau chiffrées arrivent – par exemple, un paquet IPsec encapsulé en ESP – le noyau peut les déchiffrer directement dans une page de destination plutôt que d'allouer un nouveau tampon et de procéder à deux copies. Ce processus est rapide et, pour la plupart des destinations, il est sûr, car la page de destination est allouée par le noyau à cette fin.

Une erreur « Dirty Frag » se produit lorsque la page de destination est n'est pas propriété privée. Grâce à des splice(2) ou sendfile(2) soigneusement élaborées, un processus non privilégié peut faire en sorte que le chemin de réception ESP ou RxRPC du noyau déchiffre les données entrantes directement dans une page qui alimente actuellement le cache de pages – y compris les pages contenant des fichiers sensibles tels que /etc/passwd ou /usr/bin/su.

Les octets déchiffrés sont sous le contrôle de l'attaquant (celui-ci a choisi le texte en clair avant de le chiffrer et de l'envoyer). Comme le noyau n'utilise pas la technique COW (Copy-on-Write) ni n'isole d'une autre manière la page de destination, l'écriture se fait dans la copie partagée du cache de pages. Les lectures ultérieures du fichier – y compris celles effectuées par login, sudoou su – renvoient le contenu modifié.

Le fichier sur le disque reste inchangé. Cependant, les lectures suivantes peuvent utiliser la version mise en cache modifiée au lieu du contenu d'origine du système de fichiers.

Deux chemins sont enchaînés pour assurer la couverture de la distribution :

• Le chemin ESP nécessite la création d'un espace de noms utilisateur sans privilèges, ce qu'Ubuntu bloque via AppArmor mais que la plupart des autres distributions autorisent.
• Le chemin RxRPC nécessite le chargement du module rxrpc.ko, que la plupart des distributions ne fournissent pas par défaut – contrairement à Ubuntu. Le bloc d'espace de noms d'Ubuntu est pris en charge par RxRPC ; pour les autres, l'absence de rxrpc est compensée par ESP.

Ensemble, elles couvrent les configurations de renforcement les plus courantes.

Ce qui rend ce bug particulièrement dangereux dans la pratique :

• Déterministe : Pas de fenêtre de concurrence, pas de primitive sensible au temps.
• Silence en cas d'échec : Les tentatives infructueuses ne provoquent généralement pas de panique au niveau du noyau.
• Taux de réussite élevé : suffisamment fiable pour que le PoC public fonctionne du premier coup.
• Exploitation rapide des failles : Des chaînes d'exploits publiques sont apparues avant que les correctifs coordonnés ne soient mis en place, réduisant considérablement le temps de réaction des défenseurs.

ip xfrm policy list 2>/dev/null | head
ss -tunap | grep -i rxrpc

sudo 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; true"

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Détection

Il n'existe actuellement aucune méthode de détection a posteriori largement reconnue ou fiable permettant de confirmer qu'une exploitation de « Dirty Frag » a réussi. Les fichiers sur le disque restent intacts, et l'attaque ne laisse aucune trace de système d'appel aussi caractéristique que celle de « Dirty Pipe ». Cela dit, certains indices méritent d'être recherchés :

• Chargement inattendu de esp4, esp6ou rxrpc sur des hôtes qui n'ont rien à voir avec IPsec ou AFS. Règle Auditd :

-w /sbin/modprobe -p x -k module_load

• Création de nouveaux espaces de noms réseau par des utilisateurs sans privilèges sur des systèmes où cela ne fait pas partie de la charge de travail habituelle. Suivi via unshare ou eBPF.
• Exécution en mode setuid par des comptes n'ayant jamais appelé su ou sudo, en particulier peu après une activité intensive utilisant splice/sendfile.
• À l'attention des clients d'Imunify360 : des indicateurs liés au script de déploiement de la preuve de concept (PoC) publique ont été ajoutés à sa liste noire.

Il s'agit là d'indications, et non de garanties. Considérez que tout hôte sur lequel un utilisateur local non fiable a eu accès au shell pendant la période d'exposition est potentiellement compromis.

Liste de contrôle des mesures correctives prioritaires

1. Correctif : Appliquez un correctif sans redémarrage ou déployez immédiatement un noyau corrigé. Les utilisateurs de KernelCare peuvent protéger les noyaux pris en charge en cours d'exécution sans redémarrage, en attendant que les fenêtres de maintenance standard rattrapent leur retard. Sinon, installez les noyaux corrigés par le fournisseur et redémarrez les systèmes concernés dès que possible.
2. Si vous ne pouvez pas appliquer le correctif immédiatement, appliquez la mesure d'atténuation consistant à bloquer le module décrite ci-dessus, après vous être assuré que vous ne dépendez pas d'IPsec ou de RxRPC.
3. Audit des accès locaux : Vérifiez qui dispose actuellement d'un shell sur les hébergements mutualisés, les exécuteurs CI/CD, les serveurs de build et les systèmes multi-locataires. Révoquez les accès qui ne sont pas nécessaires pendant cette période.
4. Recherche : Exécutez les requêtes de détection ci-dessus sur la fenêtre d'exposition.
5. Redémarrer après l'application du correctif : Cela effacera toutes les pages mises en cache potentiellement modifiées ainsi que l'ancien noyau.

Pourquoi les bugs comme « Dirty Frag » apparaissent-ils plus rapidement ?

Dirty Frag reflète également une tendance plus générale du secteur : l'audit assisté par l'IA permet de détecter plus rapidement des failles profondes et persistantes dans les chemins de code critiques pour les performances.

Dans un article récent, Igor Seletskiy, PDG de TuxCare, a fait valoir que les techniques modernes d'analyse assistée par l'IA réduisent considérablement le temps nécessaire pour détecter les vulnérabilités subtiles du noyau et de l'infrastructure qui, auparavant, échappaient à l'examen pendant des années.

Dirty Frag correspond parfaitement à ce schéma : une faille de propriété de la mémoire cache des pages dissimulée au sein de chemins réseau hautement performants, désormais exploitée pour permettre une élévation de privilèges fiable, avec un code d'exploitation public déjà en circulation.

Références

CVE-2026-43284 (Écriture dans le cache de page xfrm-ESP) — Entrée NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-43284

CVE-2026-43500 (Écriture dans le cache de pages RxRPC) — Entrée NVD : https://nvd.nist.gov/vuln/detail/CVE-2026-43500

• Remarque : l'entrée RxRPC est réservée au suivi, l'entrée NVD n'ayant pas encore été publiée ; la page peut donc afficher la mention « RÉSERVÉ » jusqu'à ce qu'elle soit mise à jour.

Compte rendu original du chercheur — Hyunwoo Kim (@v4bel) :

• Site hébergé : https://dirtyfrag.io
• Documentation technique complète sur GitHub : https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
• Référentiel PoC / README : https://github.com/V4bel/dirtyfrag
• Courriel d'alerte de sécurité OSS (7 mai 2026) : https://www.openwall.com/lists/oss-security/2026/05/07/8

Série de correctifs du noyau en amont (lore.kernel.org) :

• Fil de discussion sur le correctif RxRPC (mentionné dans l'avis de sécurité d'AlmaLinux) : https://lore.kernel.org/all/afKV2zGR6rrelPC7@v4bel/
• Pour le correctif ESP fusionné, la référence de commit canonique est mainline f4c50a4034e6: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4

Avis AlmaLinux : https://almalinux.org/blog/2026-05-07-dirty-frag/

Résumé

Nom de l'article

Guide sur les failles permettant d'accéder aux privilèges root sous Linux, les mesures d'atténuation et les correctifs

Description

Dirty Frag permet d'obtenir de manière fiable des privilèges root sous Linux à l'aide d'exploits accessibles au public. Découvrez son fonctionnement, les personnes concernées et bien plus encore

Auteur

Chris DeMars

Nom de l'éditeur

de TuxCare

Logo de l'éditeur