🐧 Dirty Frag : anatomie d’une nouvelle élévation de privilèges critique dans le noyau Linux

Introduction

Quelques années après Dirty COW puis Dirty Pipe, une nouvelle vulnérabilité baptisée Dirty Frag vient rappeler une réalité fondamentale : le page cache Linux reste une surface d’attaque extrêmement sensible.

Dirty Frag est une faille d’élévation de privilèges locale (Local Privilege Escalation – LPE) affectant une très large portion des noyaux Linux modernes. Le bug permet à un utilisateur non privilégié de modifier indirectement des pages mémoire associées à des fichiers protégés, puis d’obtenir un accès root de manière particulièrement fiable. Contrairement à de nombreuses LPE historiques, l’exploitation ne repose ni sur un race condition fragile, ni sur un comportement aléatoire difficile à stabiliser.

L’intérêt technique de Dirty Frag est immense, car cette vulnérabilité illustre une nouvelle évolution d’une famille de bugs très spécifique du noyau Linux : les corruptions du page cache via des mécanismes zero-copy.

---

Contexte : la lignée Dirty COW → Dirty Pipe → Copy Fail → Dirty Frag

Pour comprendre Dirty Frag, il faut d’abord comprendre la logique commune derrière ces vulnérabilités.

Toutes exploitent un invariant dangereux :

le noyau Linux manipule des pages mémoire partagées entre fichiers, cache disque et buffers réseau afin d’éviter les copies inutiles.

Cette optimisation est au cœur des performances Linux modernes.

Le problème apparaît lorsque :

• une page supposée read-only
• ou une page issue d’un fichier protégé
• est réinjectée dans une structure noyau modifiable
• sans que les vérifications de permissions soient correctement réappliquées

Dans Dirty COW, le problème concernait le mécanisme Copy-On-Write.

Dans Dirty Pipe, le problème concernait les pipe_buffer.

Dans Dirty Frag, le problème se déplace vers :

• les fragments réseau
• les structures sk_buff
• et certains chemins réseau zero-copy du noyau

---

Le rôle central du Page Cache Linux

Le page cache est une couche fondamentale du noyau Linux.

Lorsqu’un fichier est lu :

1. le contenu disque est chargé en mémoire
2. stocké dans des pages RAM
3. puis partagé entre différents sous-systèmes du noyau

Schématiquement :

Disque
   ↓
Page Cache
   ↓
read(), mmap(), splice(), sendfile(), réseau, etc.

L’objectif est simple :

• éviter les copies mémoire
• limiter les accès disque
• accélérer les E/S

Le problème est qu’une même page mémoire peut être :

• référencée par plusieurs objets noyau
• utilisée par des mécanismes différents
• parfois supposée immuable
• parfois modifiable

La sécurité repose donc entièrement sur :

• les flags ;
• les références ;
• les permissions ;
• et la cohérence des chemins de traitement.

Une simple erreur logique suffit à transformer une page read-only en page modifiable.

---

Dirty Pipe : la base conceptuelle

Dirty Frag dérive directement des concepts introduits par Dirty Pipe.

Dans Dirty Pipe :

• splice() injectait une référence vers une page du page cache dans un pipe_buffer
• certains flags n’étaient pas correctement réinitialisés
• l’écriture dans le pipe permettait ensuite d’écraser la page cache associée au fichier cible

Conceptuellement :

Fichier read-only
        ↓
Page cache
        ↓
splice()
        ↓
pipe_buffer corrompu
        ↓
write()
        ↓
Modification du cache mémoire

Le disque n’était même pas forcément modifié immédiatement :

• seule la vue mémoire du fichier changeait
• ce qui suffisait pour exécuter du code arbitraire

Dirty Frag applique exactement la même philosophie … mais via la pile réseau.

---

Le cœur technique de Dirty Frag

Selon les premières analyses publiques, Dirty Frag exploite deux classes de bugs :

• xfrm-ESP Page-Cache Write
• RxRPC Page-Cache Write

La vulnérabilité cible le champ frag des structures sk_buff.

---

Les structures sk_buff

Dans Linux, presque tout le trafic réseau transite via :

struct sk_buff

Cette structure représente un paquet réseau.

Elle contient :

• les headers
• les métadonnées
• les pointeurs
• les fragments mémoire associés au paquet

Exemple simplifié :

struct sk_buff {
    ...
    skb_frag_t frags[MAX_SKB_FRAGS];
    ...
};

Les frags permettent :

• d’éviter les copies mémoire
• de référencer directement des pages existantes
• notamment dans les chemins réseau zero-copy

C’est précisément là que Dirty Frag devient dangereux.

---

Le mécanisme « zero-copy »

Linux utilise massivement des optimisations zero-copy :

• splice()
• sendfile()
• MSG_ZEROCOPY
• chemins DMA réseau
• transferts page-cache → socket

Le principe :

Au lieu de :
fichier → buffer → socket

Linux fait :
page cache → socket

Donc :

• aucune copie
• meilleures performances
• moins de CPU

Mais cela implique qu’une page issue d’un fichier peut être directement attachée à un buffer réseau.

Et si ce buffer réseau devient modifiable … la page cache originale devient modifiable aussi.

---

L’erreur logique exploitée

Dirty Frag semble provenir d’un problème de gestion :

• des références mémoire
• des droits d’écriture
• et des flags associés aux fragments réseau

Le scénario général ressemble à ceci :

1. Référence vers page cache protégée
2. Injection dans skb->frag
3. Réutilisation incorrecte du fragment
4. Écriture autorisée
5. Corruption du page cache
6. Exécution privilégiée

Autrement dit, le noyau croit manipuler un buffer réseau modifiable, alors qu’il manipule en réalité une page issue d’un fichier système protégé.

---

Pourquoi l’exploitation est particulièrement grave

Plusieurs éléments rendent Dirty Frag extrêmement critique.

1. Pas de race condition

Contrairement à Dirty COW :

• pas besoin de synchronisation complexe
• pas de compétition entre threads
• pas de timing précis

Le bug est déterministe.

2. Très forte stabilité

Les premiers retours indiquent :

• taux de réussite élevé
• absence fréquente de kernel panic
• exploitation reproductible

C’est extrêmement rare pour une LPE noyau moderne.

3. Surface d’impact énorme

La faille affecterait :

• Ubuntu
• Debian
• Fedora
• RHEL
• AlmaLinux
• Arch
• OpenSUSE
• WSL2
• et probablement la majorité des noyaux ≥ 4.14

---

Chaîne d’exploitation typique

Une exploitation réaliste pourrait suivre cette logique :

Utilisateur non privilégié
        ↓
Création d’un chemin réseau vulnérable
        ↓
Référence vers page cache d’un fichier SUID
        ↓
Corruption du contenu mémoire
        ↓
Injection de payload
        ↓
Exécution du binaire SUID
        ↓
root

Le scénario le plus classique consiste à cibler :

• /usr/bin/su
• /usr/bin/sudo
• /etc/passwd
• ou d’autres fichiers utilisés par des processus privilégiés.

---

Pourquoi les modules ESP et RxRPC sont impliqués

Les mitigations temporaires recommandent de désactiver :

esp4
esp6
rxrpc

Cela suggère fortement que :

• certains chemins IPsec (xfrm)
• et certains mécanismes RxRPC
• exposent les primitives vulnérables

Le point intéressant est que :

• ces modules manipulent énormément de fragments réseau
• utilisent des chemins optimisés
• et réemploient agressivement des pages mémoire

Autrement dit, Dirty Frag semble être un effet secondaire classique de l’optimisation zero-copy poussée à l’extrême.

---

Comparaison Dirty Pipe vs Dirty Frag

Caractéristique	Dirty Pipe	Dirty Frag
Sous-système	Pipes	Réseau
Structure vulnérable	pipe_buffer	sk_buff
Primitive clé	splice()	Fragments réseau
Cible	Page cache	Page cache
Race condition	Non	Non
Difficulté exploitation	Faible	Faible
Impact	Root local	Root local
Type	Page-cache overwrite	Page-cache overwrite

Dirty Frag démontre surtout une chose importante :

la classe entière des « page-cache write primitives » est loin d’être éradiquée.

---

Pourquoi cette famille de bugs continue d’apparaître

Le problème est structurel.

Linux moderne repose massivement sur :

• le partage mémoire
• les optimisations zero-copy
• les références croisées
• les buffers réutilisables

Plus les performances augmentent, plus les frontières deviennent floues entre :

• mémoire réseau
• mémoire fichier
• mémoire utilisateur
• cache disque

Chaque optimisation réduit les copies, mais augmente le couplage entre sous-systèmes.

Et chaque couplage augmente le risque :

• d’alias mémoire
• de confusion de permissions
• ou de corruption logique

Dirty Frag illustre parfaitement cette tendance.

---

Implications sécurité réelles

Même si Dirty Frag est une LPE (donc locale), la menace est énorme car aujourd’hui :

• un conteneur compromis
• un shell web
• une clé SSH volée
• un utilisateur low-privilege
• une sandbox cassée

suffisent à obtenir root immédiatement.

Dans une infrastructure moderne :

• Kubernetes
• Docker
• CI/CD
• hébergement mutualisé
• environnements cloud

une LPE fiable devient souvent l’étape finale d’une compromission complète.

---

Mitigations actuelles

En attendant les correctifs noyau :

cat <<EOF | sudo tee /etc/modprobe.d/disable-dirtyfrag.conf
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

sudo modprobe -r esp4 esp6 rxrpc

Mais attention :

• cela peut casser IPsec
• certains VPN
• certaines fonctionnalités réseau avancées

---

Conclusion

Dirty Frag est probablement l’une des vulnérabilités Linux les plus intéressantes techniquement depuis Dirty Pipe.

Elle démontre plusieurs réalités fondamentales :

• les primitives zero-copy restent extrêmement dangereuses
• le page cache Linux constitue une surface d’attaque critique
• les frontières entre réseau et fichiers deviennent de plus en plus poreuses
• les bugs logiques sont désormais plus dangereux que les corruptions mémoire classiques

Surtout, Dirty Frag montre que la classe entière des vulnérabilités « Dirty-* » n’est pas un accident isolé, mais probablement une conséquence structurelle de l’architecture moderne du noyau Linux.

Et tant que Linux continuera à privilégier :

• les performances
• le partage mémoire
• les chemins sans copie

de nouvelles variantes apparaîtront probablement encore.