Dirty Frag : la faille Linux qui donne les droits root — CVE-2026-43284 & CVE-2026-43500

Qu’est-ce que Dirty Frag ?

Dirty Frag est une classe de vulnérabilités du noyau Linux divulguée publiquement le 7 mai 2026. Elle regroupe deux failles d’élévation de privilèges locale (Local Privilege Escalation — LPE) permettant à un utilisateur sans droits d’obtenir un accès root sur les distributions Linux les plus répandues.

Les deux CVE associées sont :

  • CVE-2026-43284 — composant xfrm/ESP (esp4, esp6)
  • CVE-2026-43500 — composant RxRPC

Le nom « Dirty Frag » fait écho aux célèbres Dirty COW et Dirty Pipe, et s’inscrit dans la même famille de vulnérabilités exploitant une écriture illégitime dans le cache de pages du noyau.

Comment fonctionne la faille ?

La vulnérabilité se situe dans le chemin de déchiffrement en place (in-place decryption) des modules esp4, esp6 et rxrpc.

Lorsque le noyau reçoit des paquets chiffrés et les déchiffre directement dans des pages de mémoire non exclusivement détenues par le noyau — par exemple des pages atteintes via les appels système splice(2) ou sendfile(2) — un processus non privilégié peut conserver une référence à ces pages après déchiffrement.

Résultat : l’attaquant obtient un primitif d’écriture dans le cache de pages du noyau. Le PoC public (proof-of-concept) disponible sur GitHub exploite ce primitif pour obtenir un shell root en une seule commande.

Pourquoi c’est particulièrement grave ?

  • Pas de condition de concurrence (pas de race condition) : c’est un bug logique déterministe, beaucoup plus fiable qu’une attaque de type race.
  • Taux de succès élevé : l’exploit ne fait pas crasher le noyau en cas d’échec.
  • PoC public disponible : le code d’exploitation est déjà diffusé publiquement.
  • Large surface d’attaque : touche la quasi-totalité des distributions Linux majeures.

Quelles distributions sont affectées ?

Les distributions confirmées comme vulnérables incluent :

  • Ubuntu (toutes versions LTS récentes)
  • Red Hat Enterprise Linux (RHEL)
  • CentOS Stream
  • AlmaLinux
  • Fedora
  • openSUSE Tumbleweed
  • Et probablement toute distribution basée sur un noyau Linux non patché.

Note : la faille est locale. Un attaquant doit déjà disposer d’un accès utilisateur (shell) sur la machine pour l’exploiter. Elle n’est pas exploitable à distance de manière directe, mais dans un contexte d’hébergement mutualisé ou de compromission initiale, elle est critique.

Comment se protéger ?

1. Appliquer les mises à jour noyau dès que disponibles

Le patch pour le composant ESP a été mergé dans l’arbre netdev upstream le 7 mai 2026. La plupart des distributions ont publié ou publient leurs correctifs. Mettez à jour votre noyau immédiatement.

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade

# RHEL / AlmaLinux / CentOS Stream
sudo dnf update kernel

# Après la mise à jour, redémarrer la machine
sudo reboot

Vérifiez la version installée après reboot :

uname -r

2. Mitigation immédiate — désactiver les modules vulnérables

Si vous ne pouvez pas redémarrer immédiatement après une mise à jour, ou si le patch n’est pas encore disponible pour votre distribution, vous pouvez désactiver les modules incriminés :

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
  > /etc/modprobe.d/dirtyfrag.conf"

sudo rmmod esp4 esp6 rxrpc 2>/dev/null; true

Cette commande :

  • Crée un fichier de configuration qui empêche le chargement des modules esp4, esp6 et rxrpc au démarrage.
  • Tente de décharger ces modules s’ils sont déjà en mémoire (l’erreur est ignorée si le module n’est pas chargé).

Impact de cette mitigation : les modules ESP sont utilisés pour le chiffrement IPsec (VPN de type IPsec). Si vous n’utilisez pas IPsec, cette désactivation n’a aucun impact fonctionnel. RxRPC est utilisé pour le protocole AFS (Andrew File System), très peu répandu.

3. Vérifier que les modules ne sont pas chargés

lsmod | grep -E 'esp4|esp6|rxrpc'

Si la commande ne retourne rien, les modules sont déjà déchargés ou non présents.

Que faire si vous êtes sur un VPS ou un hébergement cloud ?

Sur un VPS ou un serveur dédié, le noyau est sous votre contrôle. Suivez les étapes ci-dessus. Sur un hébergement cloud managé (AWS, GCP, Azure, Hetzner…), le fournisseur gère les mises à jour noyau — vérifiez leurs bulletins de sécurité.

Pour les environnements Docker : les conteneurs partagent le noyau de l’hôte. Patchez le noyau de l’hôte, pas seulement les conteneurs.

Ressources officielles

Laisser un commentaire