Dirty Frag (CVE-2026-43284 et CVE-2026-43500)

Elévation de privilèges locale universelle dans le noyau Linux

Résumé exécutif

Le 7 mai 2026, le chercheur Hyunwoo Kim (alias @v4bel) a divulgué publiquement une nouvelle classe de vulnérabilités du noyau Linux baptisée Dirty Frag (1) (2). Cette divulgation, anticipée à la suite d’une rupture d’embargo par un tiers non lié au processus de coordination, expose une chaîne d’exploitation reliant deux primitives d’écriture en page cache : xfrm-ESP Page-Cache Write (CVE-2026-43284) et RxRPC Page-Cache Write (CVE-2026-43500) (3) (4).

L’exploitation permet à un utilisateur local non privilégié d’obtenir les droits root sur la majorité des distributions Linux maintenues, sans condition de course (race condition) et avec un taux de réussite très élevé (5). Un proof-of-concept fonctionnel est public depuis le 7 mai 2026 et précède la publication des correctifs sur la plupart des distributions (1). La gravité est évaluée à CVSS 3.1 = 7.8 (HIGH) par Canonical et Red Hat (6) (3).

Cette publication décrit le périmètre, la chaîne technique, les conditions d’exploitation, les mitigations applicables immédiatement et les pistes de détection.

1. Identification

Identifiants CVE

• CVE-2026-43284 : xfrm-ESP Page-Cache Write (modules esp4, esp6)
• CVE-2026-43500 : RxRPC Page-Cache Write (module rxrpc)

Dénomination publique : Dirty Frag (alias Copy Fail 2, Copy Fail 2: Electric Boogaloo) (4) (7).

Découverte et signalement : Hyunwoo Kim (@v4bel), rapport privé aux mainteneurs du noyau Linux les 29 et 30 avril 2026, soumission des correctifs sur la liste netdev, transmission à linux-distros@vs.openwall.org le 7 mai 2026 (8).

Divulgation publique : 7 mai 2026, à la suite de la publication non concertée des détails techniques par un tiers, contraignant le chercheur à publier le write-up et le PoC avant la sortie des correctifs distribution (9) (8).

Score CVSS : 7.8 (HIGH) selon les évaluations Canonical et Red Hat. Aucun score officiel n’est encore présent sur le NVD au moment de la rédaction (6) (3).

Comparaisons : Dirty Frag étend la classe de bugs représentée par Dirty Pipe (CVE-2022-0847) et Copy Fail (CVE-2026-31431). Contrairement à Dirty Cow (CVE-2016-5195), il s’agit d’un défaut logique déterministe sans fenêtre temporelle à gagner (5) (10).

2. Composants affectés

Les deux vulnérabilités résident dans le chemin de déchiffrement in-place (sur place) de modules réseau du noyau Linux :

• esp4.ko et esp6.ko : prise en charge du protocole ESP (Encapsulating Security Protocol) pour IPsec.
• rxrpc.ko : protocole RxRPC, utilisé principalement par AFS (Andrew File System).

Le défaut commun se situe dans le traitement des skb (socket buffers) dont les fragments pointent vers des pages de page cache qui ne sont pas la propriété exclusive du noyau, typiquement lorsqu’un attaquant a injecté ces pages via splice(2) ou sendfile(2) (11) (12).

3. Description technique

3.1. Principe général

Lorsqu’un processus utilisateur insère, par splice(2), une référence vers une page du page cache dans un skb émis vers un socket, le code du noyau côté réception effectue une opération cryptographique directement sur cette page, en mode in-place, sans copie privative préalable (skb_cow_data est court-circuité dans le chemin rapide). La page modifiée appartient au cache de fichiers que l’attaquant a uniquement le droit de lire en temps normal, par exemple /etc/passwd ou /usr/bin/su. Toute lecture ultérieure de ce fichier renvoie alors la version altérée en mémoire (12).

Cette altération est persistante en RAM jusqu’à éviction de la page du cache, ce qui suffit pour modifier des fichiers sensibles utilisés dans la chaîne d’authentification ou l’élévation de privilèges (5).

3.2. CVE-2026-43284 : xfrm-ESP Page-Cache Write

Le défaut est introduit dans le commit cac2661c53f3 du 17 janvier 2017, qui déplace la réception ESP IPsec vers un chemin rapide de déchiffrement in-place (5). Dans esp_input, la fonction crypto_authenc_esn_decrypt est appelée directement sur le fragment, sans appel préalable à skb_cow_data. Le résultat fournit à l’attaquant une primitive d’écriture de 4 octets dans le page cache, équivalente à celle exposée par Copy Fail (4).

Le déclenchement requiert la création de user namespace et network namespace, condition généralement bloquée par défaut sur Ubuntu via AppArmor (10).

À noter : le même commit de 2017 était également la cause racine d’un débordement de tampon distinct, CVE-2022-27666 (10).

3.3. CVE-2026-43500 : RxRPC Page-Cache Write

Le défaut est introduit en juin 2023 par le commit 2dc334f1a63a, qui applique le même schéma de chemin rapide à RxRPC (8). Dans rxkad_verify_packet_1, un déchiffrement in-place d’un bloc unique avec pcbc(fcrypt) est exécuté sur le fragment (12).

Cette variante ne nécessite pas la création de namespace. Elle requiert en revanche la disponibilité du module rxrpc.ko, qui est rarement chargé par défaut sur les serveurs sans déploiement AFS, mais reste autoloadable via la création d’une socket AF_RXRPC et l’enregistrement d’une clé rxkad via add_key() (11).

Le PoC est compilé en une commande :

git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && \
gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Après exécution, le page cache reste contaminé. Le chercheur recommande d’exécuter echo 3 > /proc/sys/vm/drop_caches pour purger les pages altérées et garantir la stabilité du système (8).

3.4. Chaînage des deux primitives

Selon le write-up officiel, ni xfrm-ESP Page-Cache Write ni RxRPC Page-Cache Write ne fournissent à eux seuls une primitive suffisamment fiable pour une escalade root complète sur l’ensemble des distributions (9). Le chaînage des deux mécanismes contourne les limitations respectives :

• Sur les systèmes où la création de namespaces non privilégiés est bloquée (Ubuntu via AppArmor), xfrm-ESP seul ne se déclenche pas. La variante RxRPC prend alors le relais (10).
• Sur les systèmes où rxrpc.ko n’est pas disponible par défaut, xfrm-ESP couvre le besoin (10).

Selon Sysdig, l’exploit n’utilise que des appels système standards (socket, setsockopt, bind, vmsplice, splice, sendmsg) et des modules présents dans les paquets noyaux par défaut de toutes les distributions entreprise majeures (11).

4. Périmètre d’impact

4.1. Distributions affectées

Toute distribution Linux fournissant un noyau intégrant les commits incriminés est concernée, soit l’ensemble des branches publiées depuis 2017 pour la variante ESP et depuis 2023 pour la variante RxRPC.

Confirmations officielles :

• Ubuntu : toutes les versions supportées (14.04 LTS Trusty, 16.04 LTS Xenial, 18.04 LTS Bionic, 20.04 LTS Focal, 22.04 LTS Jammy, 24.04 LTS Noble, 25.10 Questing, 26.04 LTS Resolute) (6).
• Red Hat Enterprise Linux : RHEL 9 et 10 confirmés affectés. Sur RHEL 9 et 10, le contournement par désactivation des user namespaces non privilégiés ne couvre que la variante ESP. La variante RxRPC reste exploitable tant que rxrpc n’est pas explicitement blacklisté (3).
• AlmaLinux, CloudLinux 7h, 8, 9, 10, CentOS Stream, Fedora, openSUSE, OpenShift : confirmés affectés (4) (7).

4.2. Conteneurs et orchestrateurs

L’impact est aggravé en environnement conteneurisé exécutant des charges tierces (1) :

• Élévation de privilèges sur l’hôte depuis un conteneur sans contrainte adaptée.
• Évasion de conteneur potentielle (pas de PoC public spécifique à ce scénario à la date de rédaction).

D’après Sysdig, tout conteneur capable de créer des sockets AF_KEY, netlink XFRM ou AF_RXRPC, ce qui correspond au comportement par défaut de Docker, containerd et de la plupart des pods Kubernetes non contraints, hérite directement de l’exposition du noyau hôte (11). Les tests publiés sur EKS et GKE confirment que des pods sans seccomp explicite restent vulnérables au moins par le chemin RxRPC (13).

5. Conditions d’exploitation

Condition	xfrm-ESP (CVE-2026-43284)	RxRPC (CVE-2026-43500)
Accès local requis	Oui	Oui
Privilèges initiaux	Utilisateur non privilégié	Utilisateur non privilégié
Création de user namespace	Requise	Non requise
Module noyau requis	esp4 ou esp6 (chargeable par défaut)	rxrpc (autoloadable)
Capability nécessaire	CAP_NET_ADMIN dans le namespace	Aucune capability spécifique
Vecteur réseau distant	Aucun	Aucun

Vecteurs d’accès initial typiques observés : SSH avec compte à faible privilège, web shell, exécution post-compromission via une application vulnérable, évasion préalable de conteneur, ou compte applicatif compromis (14).

6. Détection

6.1. Indicateurs comportementaux

Les éléments suivants constituent des signaux précoces pertinents en supervision EDR ou runtime security :

• Création d’une socket AF_RXRPC (domain=33) par un processus inhabituel. RxRPC n’a pas de consommateur légitime en dehors des démons AFS (11).
• Appel à add_key("rxrpc", ...) enregistrant une clé rxkad, condition préalable au chemin RxRPC.
• Création non sollicitée de user namespace puis de network namespace par un binaire non répertorié, suivie de manipulations XFRM via netlink.
• Combinaison socket(AF_KEY) ou XFRM netlink + vmsplice + splice + sendmsg dans une chronologie compatible avec le PoC public.
• Modification anormale, en page cache, de fichiers binaires SUID (/usr/bin/su, /usr/bin/sudo, /usr/bin/passwd) ou de fichiers sensibles (/etc/passwd, /etc/shadow).

6.2. Règles disponibles

• Sysdig / Falco : règles préexistantes Copy Fail (AF_ALG Page Cache Poisoning Leading to Privilege Escalation, AF_ALG Page Cache Poisoning Targeting Sensitive File) couvrent partiellement Dirty Frag. Deux nouvelles règles dédiées aux chemins ESP et RxRPC ont été ajoutées à la Sysdig Runtime Behavioral Analytics policy (11).
• Imunify360 / CloudLinux : la chaîne bash du PoC public est intégrée dans les listes noires comportementales, en complément du correctif noyau (7).
• Microsoft Defender : monitoring actif et publication d’une analyse d’attaque post-compromission combinant Dirty Frag, modification de fichiers d’authentification GLPI/LDAP et nettoyage de sessions PHP (14).

6.3. IOC publics

Le binaire d’exploitation observé en post-compromission est notamment référencé sous le nom ./update (binaire ELF déposé après accès SSH initial), suivi d’une élévation immédiate via su (14). Le PoC d’origine est hébergé publiquement sur github.com/V4bel/dirtyfrag ; tout fichier issu de ce dépôt présent sur un système de production est à considérer comme suspect.

7. Mitigations

7.1. Application du correctif noyau (cible prioritaire)

• Mainline : CVE-2026-43284 corrigé par le commit f4c50a4034e6 (8). Au 8 mai 2026, le Linux Kernel Organization a publié les correctifs liés à CVE-2026-43284 sur le NVD (14).
• CVE-2026-43500 : aucun correctif amont public à la date de rédaction. Surveiller activement les annonces des distributions et appliquer les kernel updates dès leur disponibilité (15).
• Distributions : suivre les bulletins Ubuntu (USN), Red Hat (RHSA), AlmaLinux, CloudLinux, SUSE, Debian. CloudLinux fournit également un livepatch KernelCare (7).

7.2. Mitigation immédiate par blocage des modules

Cette mitigation s’applique en attendant le correctif noyau. Elle est efficace contre les deux variantes simultanément (6) (4).

# 1. Blocage permanent des modules
sudo tee /etc/modprobe.d/dirty-frag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

# 2. Régénération de l'initramfs (toutes versions de noyau installées)
sudo update-initramfs -u -k all   # Debian / Ubuntu
# ou
sudo dracut --force               # RHEL / Alma / CloudLinux / Fedora

# 3. Déchargement immédiat si déjà chargés
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

# 4. Vérification
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules \
    && echo "Modules ENCORE chargés -- redémarrage requis" \
    || echo "Modules NON chargés -- mitigation effective"

# 5. Optionnel : purge du page cache
echo 3 | sudo tee /proc/sys/vm/drop_caches

Si les modules sont en usage actif (IPsec, AFS), le déchargement échouera et un redémarrage planifié sera nécessaire pour rendre la mitigation effective.

7.3. Mitigation partielle : blocage des user namespaces

Cette option est documentée par Red Hat. Elle ne couvre que la variante ESP et n’est suffisante que si rxrpc est par ailleurs blacklisté (3).

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Effet de bord : impact sur les conteneurs rootless, les bacs à sable navigateur et Flatpak.

7.4. Régressions fonctionnelles à anticiper

• IPsec / VPN (StrongSwan, Libreswan, etc.) : indisponible si esp4 et esp6 sont bloqués.
• AFS ou toute application reposant sur RxRPC : indisponible si rxrpc est bloqué.
• Conteneurs rootless et Flatpak : impactés par la désactivation des user namespaces.

Avant déploiement de la mitigation à grande échelle, un inventaire des hôtes utilisant IPsec ou AFS est nécessaire (recherche lsmod | grep -E 'esp4|esp6|rxrpc', audit des configurations strongSwan / ip xfrm, audit des montages afs).

7.5. Levée de la mitigation après patch

sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all   # ou dracut --force selon la distribution
sudo modprobe esp4 esp6 rxrpc     # rechargement si nécessaire

8. Comparaison avec les vulnérabilités antérieures

Vulnérabilité	CVE	Type	Déterministe	Granularité d’écriture
Dirty Cow	CVE-2016-5195	Race condition	Non	Page complète, instable
Dirty Pipe	CVE-2022-0847	Logique	Oui	Limitée (offset, flags)
Copy Fail	CVE-2026-31431	Logique	Oui	4 octets
Dirty Frag (ESP)	CVE-2026-43284	Logique	Oui	4 octets
Dirty Frag (RxRPC)	CVE-2026-43500	Logique	Oui	Plaintext attaquant à offset choisi

Selon Sysdig, Dirty Frag remplace la primitive de 4 octets de Copy Fail par un plaintext entièrement contrôlé par l’attaquant, à un offset arbitraire, en un seul tir (11). Cette caractéristique en fait une primitive substantiellement plus puissante.

L’hypothèse formulée par Sysdig est que la durée écoulée entre l’introduction des défauts (2017 et 2023) et leur découverte suggère un appui d’outils d’analyse assistée par IA dans le travail de recherche (11).

9. Recommandations CERT / VOC

Court terme (immédiat)

1. Inventorier l’ensemble des hôtes Linux du périmètre, conteneurs et nœuds Kubernetes inclus.
2. Identifier les hôtes utilisant IPsec et AFS pour qualifier le risque de régression de la mitigation.
3. Déployer la mitigation par blacklist des modules esp4, esp6, rxrpc sur les hôtes ne consommant pas IPsec ni AFS.
4. Pour les hôtes IPsec en production sans alternative immédiate, envisager le contournement Red Hat (user.max_user_namespaces=0) en complément du blocage de rxrpc uniquement, en mesurant l’impact sur les charges rootless.
5. Activer ou renforcer les règles de détection EDR ciblant la création de sockets AF_RXRPC et les séquences vmsplice + splice + opérations XFRM.

Court à moyen terme

6. Suivre la publication des kernel updates sur les bulletins distribution officiels (USN, RHSA, ALSA, CLSA, SUSE-SU, DSA).
7. Planifier les redémarrages nécessaires à l’application des correctifs noyau ou activer KernelCare / livepatch selon la disponibilité.
8. Auditer les conteneurs Kubernetes pour s’assurer qu’un profil seccomp restrictif est appliqué par défaut, et envisager RuntimeDefault à minima sur les pods exposés à des charges tierces (13).
9. Pour les environnements multi-tenants ou exécutant du code non maîtrisé, considérer le risque comme actif jusqu’à confirmation du déploiement complet du patch noyau.

Moyen terme

10. Réévaluer la posture de chargement des modules noyau réseau exotiques, notamment rxrpc et toute famille AF_* non utilisée, dans une logique de réduction de surface d’attaque.
11. Industrialiser la vérification continue de la présence du fichier /etc/modprobe.d/dirty-frag.conf ou équivalent sur l’ensemble du parc, jusqu’à la fin du cycle de mise à jour.
12. Intégrer Dirty Frag dans les scénarios de threat hunting portant sur les compromissions post-initiales avec élévation de privilèges locale.

10. Calendrier de divulgation

• 29 et 30 avril 2026 : signalement privé aux mainteneurs du noyau Linux par Hyunwoo Kim, soumission des correctifs sur la liste netdev (9).
• 7 mai 2026 : transmission à linux-distros@vs.openwall.org ; rupture de l’embargo par un tiers et publication forcée du write-up et du PoC le même jour (1) (8).
• 8 mai 2026 : attribution des identifiants CVE-2026-43284 et CVE-2026-43500 ; publication par Canonical, Red Hat, AlmaLinux, CloudLinux et autres acteurs ; correctif amont publié par le Linux Kernel Organization pour CVE-2026-43284 (14) (6).

Sources

• (1) Wiz Research, Dirty Frag (CVE-2026-43284) Linux Privilege Escalation : https://www.wiz.io/blog/dirty-frag-linux-kernel-local-privilege-escalation-via-esp-and-rxrpc
• (2) GitHub V4bel/dirtyfrag, Repository officiel du PoC et write-up Dirty Frag : https://github.com/V4bel/dirtyfrag
• (3) Red Hat Security Bulletin, RHSB-2026-003 Networking subsystem Privilege Escalation – Linux Kernel (Dirty Frag) : https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
• (4) CloudLinux Blog, Dirty Frag (CVE-2026-43284, CVE-2026-43500): Mitigation and Kernel Update on CloudLinux : https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
• (5) Mondoo Blog, Dirty Frag: Universal Linux LPE via Page Cache Writes : https://mondoo.com/blog/dirty-frag-universal-linux-lpe-via-page-cache-writes
• (6) Canonical Ubuntu Blog, Dirty Frag Linux kernel local privilege escalation vulnerability mitigations : https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
• (7) Tenable Blog, Dirty Frag (CVE-2026-43284, CVE-2026-43500): Frequently Asked Questions about this Linux kernel privilege escalation vulnerability chain : https://www.tenable.com/blog/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-linux-kernel-lpe
• (8) GitHub V4bel/dirtyfrag, README et write-up technique : https://github.com/V4bel/dirtyfrag/blob/master/README.md
• (9) Help Net Security, Dirty Frag: Unpatched Linux vulnerability delivers root access : https://www.helpnetsecurity.com/2026/05/08/dirty-frag-linux-vulnerability-cve-2026-43284-cve-2026-43500/
• (10) The Hacker News, Linux Kernel Dirty Frag LPE Exploit Enables Root Access Across Major Distributions : https://thehackernews.com/2026/05/linux-kernel-dirty-frag-lpe-exploit.html
• (11) Sysdig, Dirty Frag (CVE-2026-43284 and CVE-2026-43500): Detecting unpatched local privilege escalation via Linux Kernel ESP and RxRPC : https://www.sysdig.com/blog/dirty-frag-cve-2026-43284-and-cve-2026-43500-detecting-unpatched-local-privilege-escalation-via-linux-kernel-esp-and-rxrpc
• (12) GitHub V4bel/dirtyfrag, write-up technique détaillé : https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md
• (13) Juliet Security, Dirty Frag in Kubernetes: EKS and GKE Exposed With Unset Seccomp : https://juliet.sh/blog/we-tested-dirty-frag-in-kubernetes-eks-gke-talos-seccomp
• (14) Microsoft Security Blog, Active attack: Dirty Frag Linux vulnerability expands post-compromise risk : https://www.microsoft.com/en-us/security/blog/2026/05/08/active-attack-dirty-frag-linux-vulnerability-expands-post-compromise-risk/
• (15) Security Boulevard, Dirty Frag (CVE-2026-43284, CVE-2026-43500): Frequently asked questions about this Linux kernel privilege escalation vulnerability chain : https://securityboulevard.com/2026/05/dirty-frag-cve-2026-43284-cve-2026-43500-frequently-asked-questions-about-this-linux-kernel-privilege-escalation-vulnerability-chain/