
Introduction
Quelques jours seulement après la divulgation de Dirty Frag (cf. l’article détaillée que j’ai rédigé ici), une nouvelle vulnérabilité du noyau Linux est apparue, j’ai nommé Fragnesia (CVE-2026-46300).
Cette faille permet à un utilisateur local non privilégié d’obtenir les droits root en exploitant une corruption logique du page cache du noyau Linux à travers le sous-système XFRM ESP-in-TCP.
Contrairement à de nombreuses LPE (Local Privilege Escalation) historiques reposant sur des race conditions complexes ou des primitives mémoire instables, Fragnesia fournit un mécanisme particulièrement fiable et déterministe pour modifier des fichiers pourtant montés en lecture seule.
Dans cet article, nous allons détailler :
- le contexte technique de la vulnérabilité
- le fonctionnement interne du page cache Linux
- le rôle des structures
sk_buff - l’erreur logique dans
skb_try_coalesce() - la manière dont l’écriture arbitraire devient une élévation de privilèges
- les implications sécurité pour les environnements modernes (containers, CI/CD, multi-tenant)
- les mitigations et correctifs
Contexte : après Dirty Frag, Fragnesia
Fragnesia appartient à la même famille de vulnérabilités que Dirty Frag : une classe de bugs permettant d’écrire dans le page cache de fichiers protégés.
Le chercheur William Bowling a découvert la vulnérabilité dans le sous-système :
xfrmESP-in-TCP- gestion des fragments réseau (
skb fragments)
La vulnérabilité est décrite comme un bug logique dans la gestion des fragments partagés (shared frags) lors des opérations de coalescing de buffers réseau.
Le nom « Fragnesia » provient du fait que le noyau « oublie » qu’un fragment mémoire est partagé (nos chers puristes français pourraient nommée cette vulnérabilité « amnésique du fragment »).
Rappel fondamental : le page cache Linux
Avant d’expliquer l’exploitation, il faut comprendre un élément clé du noyau Linux :
Le page cache
Le noyau Linux maintient en mémoire des pages correspondant aux fichiers récemment utilisés :
Disque <---> Page Cache <---> Processus
Quand un binaire est exécuté :
/usr/bin/su
son contenu est chargé dans le page cache.
Les processus lisent généralement les données depuis ce cache mémoire plutôt que directement depuis le disque.
Propriété critique : le page cache est partagé
Le page cache est :
- global au système
- partagé entre processus
- partagé entre containers
- partagé entre namespaces
Cela signifie que si un attaquant réussit à modifier une page du cache associée à :
/usr/bin/su
alors tous les processus utilisant ce fichier verront la version modifiée.
C’est précisément ce qui rend Fragnesia extrêmement dangereux.
Le sous-système XFRM et ESP-in-TCP
La vulnérabilité réside dans :
net/xfrm/
XFRM
XFRM est l’infrastructure Linux utilisée pour :
- IPsec
- encapsulation ESP
- politiques de transformation réseau
ESP (Encapsulating Security Payload) peut être transporté via TCP :
ESP-in-TCP
Le traitement des paquets utilise intensivement les structures :
struct sk_buff
Ce n’est pas un hasard si le nom de cette structure vous dit quelque chose si vous avez suivi l’actualité des vulnérabilités du kernel Linux !
Les structures sk_buff
Sous Linux, quasiment tout le trafic réseau passe par :
struct sk_buff
Cette structure représente un paquet réseau.
Elle contient notamment :
- les données du paquet
- des pointeurs vers des fragments mémoire
- des métadonnées réseau
- des flags de gestion mémoire
Simplification :
struct sk_buff {
...
skb_shared_info *shinfo;
...
}
Les fragments partagés
Pour éviter les copies mémoire coûteuses, Linux réutilise des fragments :
Page mémoire
↑
skb A
skb B
skb C
Plusieurs buffers peuvent référencer la même page physique.
Le noyau utilise alors des flags comme :
SKBFL_SHARED_FRAG
afin d’indiquer :
Attention, ce fragment est partagé, ne pas le modifier directement.
Le bug : perte du flag SHARED_FRAG
Le cœur de Fragnesia se situe dans :
skb_try_coalesce()
Cette fonction fusionne plusieurs fragments réseau afin d’améliorer les performances.
Le problème :
- pendant certaines opérations de coalescing
- le flag
SKBFL_SHARED_FRAGn’est pas correctement propagé - le noyau croit alors que le fragment est privé
- il effectue une écriture directe dans une page partagée
Autrement dit :
Fragment réellement partagé
↓
Flag perdu
↓
Le noyau pense que la mémoire est privée
↓
Écriture autorisée
↓
Corruption du page cache
Pourquoi c’est catastrophique
Normalement, modifier un fichier root-owned comme :
/usr/bin/su
nécessite :
- les permissions root
- ou un accès disque privilégié
Mais Fragnesia ne modifie pas le fichier sur disque.
Elle modifie la copie mémoire du fichier présente dans le page cache.
Le VFS et les permissions UNIX sont donc totalement contournés.
De l’écriture arbitraire à root
L’exploitation suit généralement ce schéma :
1. Préparation du fragment partagé
L’attaquant force la création d’un skb référençant une page du page cache.
2. Coalescing vulnérable
Le noyau fusionne des buffers réseau :
skb_try_coalesce()
Le flag SKBFL_SHARED_FRAG disparaît.
3. Écriture dans le page cache
Le noyau autorise une écriture dans une page qui :
- appartient en réalité au page cache
- correspond à un fichier système
- est supposée read-only
4. Corruption d’un binaire SUID
Le PoC public cible :
/usr/bin/su
Le shellcode ou le patch injecté transforme le binaire afin d’obtenir :
euid=0
Pourquoi l’exploitation est particulièrement fiable
Beaucoup d’exploits kernel historiques reposent sur :
- UAF fragiles
- race conditions
- heap feng shui
- sprays mémoire complexes
Fragnesia est plus simple.
Le chercheur indique explicitement :
without requiring any race condition
Cela change énormément la stabilité de l’exploitation :
| Vulnérabilité | Stabilité |
|---|---|
| Dirty COW | dépend d’une race condition |
| Heap overflow kernel | souvent instable |
| UAF kernel | dépend du layout mémoire |
| Fragnesia | déterministe |
Pourquoi les containers sont fortement exposés
Fragnesia est particulièrement problématique dans les environnements :
- Kubernetes
- CI runners
- build farms
- PaaS multi-tenant
- hébergeurs mutualisés
Pourquoi ? Parce que le page cache est partagé entre containers !
Un container non privilégié peut donc modifier le page cache visible par l’hôte, même sans accès root dans le container.
C’est exactement le type de primitive recherché pour :
- container escape
- breakout Kubernetes
- élévation de privilèges cloud
Différence entre Dirty Frag et Fragnesia
Bien qu’ils appartiennent à la même famille, les bugs diffèrent.
Dirty Frag
Dirty Frag utilisait plusieurs vulnérabilités chaînées :
- RXRPC
- XFRM
- corruption du page cache
Fragnesia
Fragnesia :
- exploite uniquement ESP/XFRM
- repose sur un bug logique distinct
- ne nécessite pas la chaîne Dirty Frag complète
- possède son propre patch
Le correctif
Le patch proposé est extrêmement petit, seulement 2 lignes, selon les premières analyses publiques.
Le correctif consiste essentiellement à :
- préserver correctement le flag
SKBFL_SHARED_FRAG - pendant les opérations de coalescing.
En simplifiant :
if (frag_is_shared)
propagate_shared_flag();
Mitigations temporaires
En attendant les patches kernel :
modprobe -r esp4
modprobe -r esp6
modprobe -r rxrpc
ou blacklist des modules concernés.
Attention : patcher ne suffit pas toujours
Point très important :
Si la machine a déjà été compromise, le page cache peut contenir des binaires corrompus.
Certaines distributions recommandent :
echo 3 > /proc/sys/vm/drop_caches
Cela permet alors de purger le cache mémoire.
Pourquoi cette série de vulnérabilités inquiète autant
Copy Fail → Dirty Frag → Fragnesia.
Trois vulnérabilités majeures du noyau Linux révélées en peu de temps.
Le point commun : corruption de mémoire liée à des chemins réseau complexes.
Cela montre plusieurs tendances :
1. Les surfaces réseau du kernel sont gigantesques
Le noyau Linux contient :
- des décennies de compatibilité
- de multiples protocoles
- des optimisations mémoire agressives
2. Les optimisations « zero-copy » deviennent dangereuses
Pour gagner en performances :
- réutilisation de pages
- partage de fragments
- coalescing
- référence-counting complexe
Mais plus les optimisations mémoire augmentent, plus les invariants deviennent fragiles.
3. Les outils d’audit assistés par IA accélèrent la découverte
Plusieurs discussions publiques mentionnent l’usage d’outils automatisés et d’analyse assistée par IA dans la découverte de ces bugs.
Cela pourrait annoncer une augmentation massive du volume de vulnérabilités kernel découvertes dans les prochaines années.
Détection et forensic
Détecter Fragnesia est difficile car :
- le disque n’est pas modifié
- seule la mémoire cache l’est
- la compromission peut disparaître après reboot
Indicateurs possibles :
- corruption mémoire de binaires SUID
- comportement anormal de
su,sudo,passwd - modules XFRM chargés inutilement
- traces d’exploitation locales
- crashs réseau inhabituels
Microsoft indique également que les signatures utilisées pour Dirty Frag détectent certains PoC Fragnesia.
Conclusion
Fragnesia est un excellent exemple de vulnérabilité moderne du noyau Linux :
- bug logique subtil ;
- corruption indirecte ;
- exploitation déterministe ;
- contournement complet du modèle UNIX ;
- impact majeur sur les infrastructures cloud et containerisées.
Cette vulnérabilité rappelle surtout une réalité fondamentale :
la sécurité du noyau dépend désormais fortement de la cohérence des optimisations mémoire internes.
Les mécanismes modernes de performance – page cache partagé, zero-copy, coalescing, références partagées – deviennent des cibles privilégiées pour les chercheurs offensifs.
Et avec l’émergence des outils d’audit automatisés assistés par IA, il est probable que ce type de vulnérabilité ne soit qu’un début.