Fragnesia (CVE-2026-46300) : une nouvelle faille d'exécution de privilèges (LPE) dans le noyau Linux, issue de la famille Dirty Frag

En bref

Description : Une faille dans la gestion XFRM ESP-in-TCP du noyau Linux permet à un utilisateur local non privilégié d'induire des modifications contrôlées sur les pages mises en cache appartenant à des fichiers en lecture seule, y compris les binaires setuid.

Impact : Élévation des privilèges locaux au niveau root via la modification du cache de page. Le fichier sur le disque reste inchangé tandis que la copie mise en cache en mémoire est modifiée.

Systèmes concernés : Les systèmes exécutant les chemins de code skbuff concernés, y compris les noyaux ayant déjà reçu le correctif « Dirty Frag ». Le PoC public nécessite CONFIG_INET_ESPINTCP pour exploiter le bug ; les noyaux compilés sans cette option bloquent donc cette exploitation ; le défaut skbuff sous-jacent peut toutefois être exploitable via d'autres chemins. Les distributions qui restreignent par défaut les espaces de noms des utilisateurs non privilégiés (comme la configuration AppArmor d'Ubuntu) bloquent partiellement le PoC public.

Statut de l'exploit : Preuve de concept publique publiée sur GitHub immédiatement après la divulgation.

CVE ID: CVE-2026-46300

Mesures d'atténuation : Désactivez les modules ESP vulnérables ou appliquez les correctifs fournis par le fournisseur dès qu'ils sont disponibles.

État de la couverture KernelCare (mis à jour le 18 mai 2026 à 13 h 00 UTC) : Des correctifs sans redémarrage sont disponibles dans les flux main + ePortal pour AlmaLinux ELS/FIPS, Debian 11, Debian 12, la famille EL8, Rocky Linux 10, Oracle Linux 8, Oracle Linux 8 UEK 7, Oracle Linux 9, Oracle Linux 9 UEK 7, Ubuntu 22.04 (Jammy) et Ubuntu 24.04 (Noble).

kcarectl --update # pulls the patch if your kernel is in scope
kcarectl --patch-info | grep cve-2026-46300

État de la divulgation : Les détails techniques, les informations sur les versions concernées et les recommandations de mitigation sont susceptibles d'évoluer à mesure que les fournisseurs publient des avis de sécurité et que les responsables de maintenance du noyau en aval effectuent les rétroportages.

Il y a cinq jours, Linux a publié des correctifs pour « Dirty Frag ». Aujourd'hui, les responsables de la sécurité doivent faire face à une autre faille de sécurité du même type.

Fragnesia (CVE-2026-46300) est une faille de sécurité récemment révélée permettant l'escalade de privilèges en local et ciblant le sous-système XFRM ESP-in-TCP du noyau Linux. Elle a été rendue publique aujourd'hui par William Bowling, en collaboration avec l'équipe de V12 Security, accompagnée d'une preuve de concept fonctionnelle qui écrase /usr/bin/su via le cache de pages et permet d'obtenir un accès root.

La divulgation a été rendue publique sur GitHub et sur X immédiatement après la publication du correctif sur la liste de diffusion netdev, sans délai d'embargo. Au moment de la publication, aucun numéro CVE n'a été attribué, et le correctif en amont est en attente d'examen et de fusion sur netdev.

Ce qui rend Fragnesia remarquable, ce n'est pas seulement la faille en elle-même, mais aussi le moment où elle a été découverte et son contexte. Le correctif proposé (soumis par Bowling) fait explicitement référence au correctif « Dirty Frag » (f4c50a4034e6) comme l'un des deux commits qu'il « corrige » – ce qui signifie que la correction initiale de Dirty Frag a révélé un bug jusque-là latent d'une manière qui le rendait pratiquement exploitable. Selon l'article de Wiz, Hyunwoo Kim (le rapporteur initial de Dirty Frag) a également reconnu que Fragnesia était apparu comme un effet secondaire involontaire des correctifs Dirty Frag.

Le tableau d'ensemble est inquiétant : les responsables de la sécurité doivent désormais corriger deux fois la même faille en moins d'une semaine, tandis que les auteurs d'exploits réagissent presque aussi vite que les correctifs sont publiés.

Pourquoi la fragnésie est importante

Fragnesia n'est pas une classe de vulnérabilité totalement distincte de Dirty Frag. Il s'agit d'une autre voie d'exploitation passant par la même surface d'attaque ESP/XFRM, et le correctif initial de Dirty Frag fourni par l'amont ne la bloque pas complètement.

Le problème technique se situe dans skb_try_coalesce(). Lorsque cette fonction joint des fragments paginés provenant d'un sk_buff à un autre, elle supprime actuellement le SKBFL_SHARED_FRAG , même lorsque le tampon résultant contient encore des fragments appartenant à des entités externes ou soutenus par le cache de pages. Cela rompt l'invariance sur laquelle repose la gestion des entrées ESP – en particulier, la fonction skb_has_shared_frag() qui détermine si un skb non linéaire non cloné peut ignorer skb_cow_data(). Si l'on ignore la copie à l'écriture, on obtient un déchiffrement sur place directement dans la page partagée.

En d'autres termes, la solution au problème « Dirty Frag » (f4c50a4034e6) a ajouté du code qui part du principe que le marqueur « shared-frag » est exact. Or, ce marqueur n'est pas exact. Le patch candidat pour Fragnesia comporte deux corrections : : l'une pour le commit « Dirty Frag », et l'autre pour un commit beaucoup plus ancien datant de 2013 (cef401de7be8) – ce qui montre que le bug de coalescence sous-jacent existe depuis des années. Le correctif « Dirty Frag » l’a simplement rendu exploitable de manière utile.

Concrètement, cette faille aboutit au même résultat que celui qui inquiétait déjà les défenseurs la semaine dernière : la modification du cache de page de binaires privilégiés sans toucher au fichier sous-jacent sur le disque.

Si vous avez déjà mis en place la mesure d'atténuation « Dirty Frag » qui a désactivé esp4, esp6et rxrpc, vous êtes déjà protégé contre la preuve de concept publique de Fragnesia. Si vous n'avez appliqué que le correctif initial en amont, vous ne l'êtes pas.

Cette distinction revêt une importance opérationnelle, car elle confirme une tendance que les défenseurs observent de plus en plus souvent dans le cadre de l'exploitation moderne du noyau : les correctifs apportés aux bogues complexes liés à la gestion de la mémoire deviennent eux-mêmes la cible de recherches visant à les contourner rapidement.

Comment fonctionne cette faille

En gros, l'exploit fonctionne comme suit :

1. L'attaquant crée un nouvel utilisateur et un nouvel espace de noms réseau à l'aide de unshare(CLONE_NEWUSER | CLONE_NEWNET) pour obtenir CAP_NET_ADMIN au sein de l'espace de noms en bac à sable.
2. Une association de sécurité ESP-in-TCP en mode transport est établie via NETLINK_XFRM en utilisant AES-128-GCM avec une clé connue.
3. L'exploit génère une table de correspondance de flux de clés de 256 entrées à l'aide de AF_ALG , en mappant chaque valeur d'octet possible à un nonce correspondant.
4. Les pages basées sur des fichiers sont mises en file d'attente dans un flux TCP à l'aide de splice().
5. Le socket est basculé en mode mode espintcp ULP une fois que les pages ont déjà été mises en file d'attente.
6. Parce que skb_try_coalesce() a préalablement supprimé le marqueur de fragment partagé, le noyau procède au déchiffrement AES-GCM sur place directement sur les pages mises en cache partagées.
7. L'octet du flux de clés sélectionné est soumis à une opération XOR avec la page cible, ce qui produit une écriture contrôlée d'un seul octet. Répétez l'opération octet par octet jusqu'à ce que la charge utile soit écrite.

Le PoC public remplace la copie mise en cache de

/usr/bin/su avec une petite charge utile ELF indépendante de la position qui exécute :

setresuid(0,0,0);

execve("/bin/sh");

Cette faille est remarquable car elle ne repose pas sur une fenêtre de concurrence étroite qui doit aboutir exactement une seule fois. L'attaquant exécute la primitive d'écriture à plusieurs reprises jusqu'à ce que les octets souhaités soient correctement enregistrés, ce qui rend le processus bien plus déterministe que de nombreuses failles historiques du noyau liées à des conditions de concurrence.

La page mise en cache modifiée peut subsister jusqu'à son effacement ou jusqu'au redémarrage, ce qui signifie que des appels répétés du binaire ciblé peuvent continuer à donner accès au compte root, même si le hachage du fichier sur le disque reste inchangé.

Qui est le plus exposé ?

Les environnements les plus à risque sont les systèmes qui combinent :

• exécution de code local non fiable,
• espaces de noms sans privilèges activés,
• charges de travail multi-locataires,
• et la prise en charge du noyau XFRM/ESP.

C'est pourquoi il est particulièrement important de donner la priorité aux environnements suivants :

• Nœuds de travail Kubernetes
• Exécuteurs CI/CD partagés
• Plateformes d'hébergement mutualisé
• Serveurs Bastion et Jump
• Postes de travail pour développeurs
• Infrastructure de conteneurs multi-locataires

Dans le cas de ces systèmes, une faille permettant l'escalade de privilèges « locale » n'est plus guère limitée au niveau local. Un conteneur compromis, une tâche CI malveillante, une clé SSH volée ou une faille RCE au niveau de l'application peuvent tous servir de tremplin pour compromettre entièrement l'hôte.

Correction sans redémarrage de Fragnesia avec KernelCare

Pour les systèmes mentionnés ci-dessus – nœuds Kubernetes multi-locataires, exécuteurs CI partagés, hôtes bastion – la question pratique est de savoir en combien de temps vous pouvez réellement déployer un correctif. L'outil de correction sans redémarrage de TuxCare, KernelCare, a fourni des correctifs sans redémarrage pour la famille de noyaux EL8 dans les 24 heures suivant la divulgation de la faille Dirty Frag la semaine dernière, avant même la publication des errata correspondants par les éditeurs. EL9, Ubuntu, Debian et Proxmox VE ont suivi dans la même vague de publication. C'est la référence en matière de « rapidité » dans cette classe de gravité.

Pour Fragnesia, le processus va être un peu plus compliqué. Le correctif en amont est toujours sur netdev en attente de révision, ce qui signifie que le premier correctif KernelCare sera compilé à partir d'une version candidate. Si la version fusionnée par le responsable s'avère différente, il faudra s'attendre à une nouvelle compilation. Et comme ce correctif candidat comporte une balise Fixes: pointant vers un commit de 2013, il est probable que d'autres audits de skb_try_coalesce() soient nécessaires – le premier correctif sans redémarrage publié ne sera peut-être pas le dernier pour cette surface d'attaque.

C'est exactement le cas pour l'application de correctifs sans redémarrage. Deux correctifs en cinq jours pour le même sous-système, tous deux accompagnés de PoC publics avant que les errata des fournisseurs ne puissent rattraper leur retard, et un troisième qui devrait vraisemblablement suivre. L'alternative — que la section suivante détaille — consiste à mettre des modules sur liste noire, à imposer des restrictions d'espace de noms et à effectuer un redémarrage progressif non planifié dès que votre distribution publie un paquet du noyau. Les nœuds Kubernetes vidés deux fois en une semaine. Les exécuteurs CI redémarrés en cours de compilation. Des basculements de bastion que personne n'avait planifiés.

Une mise en garde honnête : certains scanners de vulnérabilités continueront de signaler la version non corrigée du paquet du noyau après l'application d'un correctif en direct, car leur logique de détection ne suit pas l'état réel du noyau en cours d'exécution. Le noyau est protégé. Il se peut que votre tableau de bord ne reflète pas cette situation pendant un jour ou deux. Prévoyez en conséquence une explication dans votre ticket.

Si vous n'utilisez pas encore KernelCare et que vous avez interrompu votre cycle de mise à jour cette semaine, c'est le moment idéal pour vous renseigner. Les nouveaux clients bénéficient d'une réduction jusqu'à la fin du mois de juin. Obtenir KernelCare → 

Atténuation

Mesures d'atténuation immédiates

La liste noire de modules utilisée pour Dirty Frag bloque également l'exploit public Fragnesia :

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Si /etc/modprobe.d/dirtyfrag.conf existe déjà suite à des mesures correctives antérieures, vous pouvez le laisser tel quel.

Avertissement opérationnel

Désactivation esp4 et esp6 interrompt le fonctionnement des VPN basés sur IPsec et ESP, y compris les déploiements utilisant strongSwan ou Libreswan. Les déploiements WireGuard ne sont pas affectés.

rxrpc est associé aux clients AFS et peut généralement être désactivé sans risque sur les serveurs classiques.

Vérifiez les dépendances opérationnelles avant de déployer ces mesures correctives à grande échelle.

Limiter les espaces de noms des utilisateurs sans privilèges

Les systèmes Ubuntu résistent en partie à cette démonstration de principe publique, car AppArmor restreint par défaut les espaces de noms des utilisateurs sans privilèges. La démonstration de principe elle-même invite les utilisateurs à désactiver :

kernel.apparmor_restrict_unprivileged_userns=0

avant leur exploitation.

Les systèmes de la famille RHEL peuvent offrir une protection similaire grâce à :

echo "user.max_user_namespaces=0" > /etc/sysctl.d/fragnesia.conf

sysctl --system

Il ne s'agit là que d'une solution partielle. Cela entraîne également des dysfonctionnements au niveau des conteneurs sans droits root, de Flatpak, des navigateurs en mode sandbox et d'autres outils dépendant des espaces de noms.

Vider le cache des pages corrompues

Étant donné que cette faille ne modifie que les pages mises en cache, les systèmes soupçonnés d'avoir été compromis doivent vider le contenu du cache des pages après la mise en place des mesures correctives :

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

Cela supprime la persistance immédiate du cache de page, mais ne garantit pas que l'attaquant n'ait pas réussi à établir une persistance plus durable par la suite. Toute exploitation réussie doit être considérée comme une compromission totale de l'hôte.

Appliquer les correctifs fournis par les éditeurs

Appliquez les mises à jour du noyau fournies par les éditeurs ou les correctifs en direct validés dès qu'ils sont disponibles pour votre distribution.

Au moment de la publication, le correctif de suivi proposé par William Bowling :

[PATCH net] net : skbuff : conserver le marqueur « shared-frag » lors de la fusion

est en attente d'examen sur la liste de diffusion netdev. Le correctif est court : deux lignes dans skb_try_coalesce() qui préservent le drapeau SKBFL_SHARED_FRAG lors du transfert des descripteurs de fragments. Les responsables du projet devraient rapidement intégrer une version de ce correctif, mais les rétroportages en aval vers les différentes distributions prendront plus de temps.

Cela est important car les responsables de la sécurité devront peut-être considérer cela comme un cycle de correctifs évolutif plutôt que comme une opération de correction ponctuelle. Les deux correctifs : indiquent qu’un travail d’audit plus approfondi du chemin de fusion skb est justifié.

Guide de détection

Les outils traditionnels de vérification de l'intégrité des fichiers sont peu adaptés à ce type d'attaque :

• Les hachages stockés sur le disque restent corrects
• AIDE et Tripwire peuvent indiquer qu'aucune modification n'a été apportée
• La modification malveillante disparaît après le vidage du cache ou le redémarrage

La détection comportementale est bien plus prometteuse.

Parmi les signes potentiels, on peut citer :

• unshare(CLONE_NEWUSER | CLONE_NEWNET) provenant de processus inattendus
• NETLINK_XFRM provenant de charges de travail sans rapport avec la fonctionnalité VPN
• D'une intensité inhabituelle utilisation de l'interface , en particulier dans les boucles serrées
• splice() Opérations à partir de fichiers standard vers des sockets TCP, suivies de modifications ULP sur le même socket

Aucun de ces éléments n'est en soi malveillant, mais leur combinaison est suffisamment suspecte pour justifier la mise en place de règles de détection à l'exécution à l'aide des outils eBPF, de Falco, de Tetragon ou de plateformes EDR sous Linux.

La tendance générale

Les recherches récentes sur l'escalade des privilèges sous Linux ont régulièrement mis en évidence des failles liées à la corruption du cache de pages, à la propriété de la mémoire partagée et au traitement in situ, notamment :

• Dirty Pipe (2022)
• Échec de la copie (2026)
• Dirty Frag (2026)
• Fragnesia (2026)

Trois d'entre eux ont fait surface en l'espace de quelques semaines seulement.

Le fil conducteur apparaît de plus en plus clairement : les chemins du noyau hautement optimisés, qui impliquent la gestion de la propriété de la mémoire partagée, la gestion des pages et le traitement in situ, continuent de générer des opérations d'écriture dangereuses lorsque les hypothèses relatives aux cas limites s'avèrent erronées.

splice(), la fusion skb, le traitement ESP et les interactions avec le cache de pages sont tous des sous-systèmes axés sur les performances. Les attaquants démontrent de plus en plus que ces optimisations peuvent devenir des voies fiables d'escalade de privilèges lorsque la sémantique de propriété est compromise.

Fragnesia se distingue également par la rapidité avec laquelle elle est apparue après la mise en place des correctifs pour Dirty Frag. V12 Security attribue une partie de ce processus de détection à des outils de sécurité basés sur l'IA, et quelle que soit la crédibilité que l'on accorde à cette affirmation, le rythme des itérations d'exploits s'accélère. Le fait que le correctif proposé comporte un balise « Fixes: » pointant vers un commit de 2013 suggère également que cette classe de bogues n'est pas épuisée : il existe probablement d'autres violations d'invariants dans le même chemin de code qui attendent d'être découvertes.

Les défenseurs doivent partir du principe que cette classe d'insectes n'a pas encore achevé son évolution.

Résumé

Nom de l'article

Fragnesia (CVE-2026-46300) : nouvelle faille LPE sous Linux qui contourne le correctif « Dirty Frag »

Description

Fragnesia (CVE-2026-46300) est une nouvelle faille de type « LPE » (exécution de code en mode utilisateur) du noyau Linux qui s'inscrit dans la lignée de la famille Dirty Frag (CVE-2026-43284, CVE-2026-43500).

Auteur

Tim Walker

Nom de l'éditeur

de TuxCare

Logo de l'éditeur