🐧 Fragnesia : plongez dans les détails d’une n-ième élévation de privilèges dans le noyau Linux par corruption du page cache

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 :

  • xfrm
  • ESP-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_FRAG n’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 COWdépend d’une race condition
Heap overflow kernelsouvent instable
UAF kerneldépend du layout mémoire
Fragnesiadé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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *