Fragnesia – Une nouvelle faille Linux dans la lignée de Dirty Frag
Bon, accrochez vous les amis, car ça enchaine sec sur le kernel Linux en ce moment… Le chercheur William Bowling de l’équipe V12 security vient de lâcher Fragnesia (CVE-2026-46300, CVSS 7.8), un nouvel exploit kernel Linux qui permet d’obtenir un accès root sur toutes les distros majeures, et ce, 8 jours seulement après le patch de Dirty Frag.
Et la mauvaise nouvelle, en fait, c’est que Fragnesia tape dans la même surface d’attaque que
Dirty Frag
, mais via un bug logique différent qui n’est pas fixé par le patch initial. Donc si vous aviez sagement mis à jour votre noyau le 8 mai dernier en pensant être tranquille, hé bah désolé, vous êtes toujours à poil !
La lignée “Dirty” continue donc tout simplement de s’allonger…
Dirty COW
en 2016, Dirty Pipe en 2022,
Copy Fail
le 1er mai 2026,
Dirty Frag
le 8 mai, et maintenant Fragnesia le 14 mai. Quatre LPE (local privilege escalation) kernel Linux en deux semaines, c’est un record je crois !
Alors comment ça marche ?
Le bug se planque dans la partie du kernel qui gère le chiffrement réseau IPsec. C’est le truc qu’on utilise pour faire du VPN d’entreprise et l’attaque détourne le moteur de chiffrement pour qu’il écrive là où il ne devrait surtout pas écrire.
Le déroulé ensuite est assez simple à comprendre. Il prend un fichier sensible déjà ouvert en lecture (genre /usr/bin/su, le programme qui fait passer en root), il le balance dans une connexion réseau, et il dit au kernel “tiens, chiffre-moi tout ça en IPsec“. Le kernel obéit gentiment, sauf qu’au lieu d’envoyer le résultat chiffré sur le réseau, il vient écraser la version du fichier qui est en mémoire avec les octets chiffrés. Du coup /usr/bin/su contient maintenant du code choisi par l’attaquant. Suffit ensuite de taper su pour devenir root.
Et là c’est le drame !
Le pire, c’est qu’il n’y a aucun “tirage au sort” dans tout ça. Pas besoin de gagner une condition de course une fois sur mille comme à l’époque de Dirty COW. Là, c’est 100% reproductible à chaque exécution, ça marche du premier coup.
La cause profonde, c’est une fonction kernel qui assemble des morceaux de paquets réseau et qui oublie au passage que certains morceaux pointent vers de la mémoire qui ne lui appartient pas vraiment (genre la mémoire d’un fichier qu’un autre process est en train de lire). Bowling appelle ça la “famille Dirty Frag” parce que c’est exactement le même genre d’amnésie qui avait permis Dirty Frag la semaine dernière.
Et le patch du 8 mai n’a pas suffi parce qu’il a juste rebouché un trou particulier, sans toucher à la fonction d’origine. D’où la sortie immédiate du PoC le 14 mai, parce qu’autant prévenir tout le monde, plutôt que de laisser un 0-day silencieux circuler dans les milieux moins recommandables d’Internet.
Testez sur votre Linux
Si vous voulez reproduire ça dans un environnement isolé (genre une VM Ubuntu 24.04 avec un kernel 6.8.0-111-generic), c’est simple :
git clone https://github.com/v12-security/pocs.git
cd pocs/fragnesia
gcc -o exp fragnesia.c && ./exp
Petite subtilité à connaître sur Ubuntu, AppArmor restreint les “user namespaces” (les bacs à sable du kernel) pour les utilisateurs non-privilégiés depuis Ubuntu 24.04. Du coup, avant de lancer l’exploit, faut faire sauter ce verrou de sécurité :
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
Et là vous récupérez un shell root sans crasher le kernel… vous allez voir, c’est presque magique !
⚠️ Attention, après le test, le /usr/bin/su en mémoire est toujours pété (il contient encore le code de l’attaquant). Donc avant de continuer à utiliser la machine, faut nettoyer ce cache mémoire :
echo 3 > /proc/sys/vm/drop_caches
Ou plus simple, vous rebootez la VM puisque la corruption est uniquement en RAM.
Alors on fait quoi maintenant ?
D’abord, du côté patch, AlmaLinux a déjà sorti des kernels corrigés (kernel-4.18.0-553.124.3.el8_10 pour AL8, kernel-5.14.0-611.54.5.el9_7 pour AL9, et kernel-6.12.0-124.56.3.el10_1 pour AL10). Ensuite, pour les autres distros (Ubuntu, Debian, RHEL, SUSE, Fedora, Gentoo, Amazon Linux, CloudLinux), c’est en cours, mais pas encore disponible partout à l’heure où j’écris ces lignes.
En attendant, la mitigation est exactement la même que pour Dirty Frag, ce qui est plutôt cool, et même pratique, si vous l’aviez déjà appliquée la semaine dernière (rien à refaire, vous êtes déjà protégé contre la nouvelle bête, c’est cadeau). Si ce n’est pas le cas, voici la commande à coller en root, à exécuter sur chaque machine concernée :
sh -c "printf 'install esp4 /bin/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"
Cette ligne bloque les trois modules vulnérables (esp4, esp6 et rxrpc) pour qu’ils ne se rechargent pas au reboot, les décharge s’ils tournent déjà, et nettoie le cache mémoire au cas où il serait déjà corrompu.
Pour rappel, ces trois modules ne servent qu’à du VPN IPsec en mode transport et à un protocole réseau exotique d’Andrew File System. Du coup, 99% des desktops et serveurs classiques ne perdent rien à les désactiver. Si vous opérez du VPN IPsec en prod par contre, là attention, faudra attendre le patch officiel de votre distro et bricoler une rotation de modules en attendant.
Une fois que votre distro pousse le patch officiel (espérons que ce sera très bientôt côté Ubuntu et Debian), vous mettez à jour le noyau, vous rebootez la bécane, et vous retirez tranquillement la conf de modprobe.
Source :
github.com/v12-security/pocs
Leave a Comment