⚠️ Avertissement

Ce dépôt est destiné à la recherche en sécurité autorisée, à l'analyse de vulnérabilités, aux environnements CTF, au débogage du noyau et aux tests défensifs.

N'utilisez pas le code de preuve de concept contre des systèmes sans autorisation explicite.

📌 Aperçu de la vulnérabilité

L'avis CVE décrit le problème comme un underflow d'entier pouvant positionner skb->data en dehors de la tête skb allouée.

🧬 Description de la vulnérabilité

La vulnérabilité existe dans le chemin de réception TUN/TAP du noyau Linux.

Le code affecté utilise le headroom de réception configuré du périphérique TUN à la fois comme headroom de paquet et lors du calcul de la quantité de données de paquet devant rester linéaire.

Une valeur de headroom surdimensionnée peut donc créer un calcul invalide dans :

SKB_MAX_HEAD(align)

Lorsque la valeur fournie dépasse la tête skb utilisable d'une page, le calcul peut produire un underflow.

Conceptuellement :

Headroom de réception surdimensionné
          │
          ▼
     SKB_MAX_HEAD()
          │
          ▼
     Underflow d'entier
          │
          ▼
    Valeur négative
          │
          ▼
      wrap size_t
          │
          ▼
Placement invalide des données skb
          │
          ▼
Corruption mémoire du noyau

L'implémentation vulnérable se trouve dans :

drivers/net/tun.c

avec tun_get_user() au cœur du chemin vulnérable.

🔬 Cause racine

Le problème sous-jacent est un headroom de réception TUN insuffisamment borné.

Le noyau peut recevoir une demande de headroom surdimensionnée via des chemins de périphériques réseau qui propagent la valeur vers TUN/TAP.

La vulnérabilité devient particulièrement intéressante lorsqu'une configuration réseau virtuelle complexe fait atteindre une grande valeur de headroom à un périphérique TUN.

La divulgation publique décrit un scénario impliquant :

Netkit
   │
   ▼
VXLAN
   │
   ▼
Open vSwitch
   │
   ▼
TUN

Une configuration d'exemple peut propager environ 4160 octets de headroom vers un port TUN brut, provoquant l'underflow de l'arithmétique vulnérable.

💥 Impact de sécurité

La corruption se produit dans la logique de gestion mémoire réseau du noyau.

Les conséquences potentielles incluent :

• Corruption mémoire du noyau
• Crash du noyau
• Déni de service
• Corruption de structures du noyau
• Exécution potentielle de code noyau
• Élévation de privilèges locale

La divulgation publique rapporte la vulnérabilité comme faisant partie d'un groupe de vulnérabilités de root local Linux et indique que le PoC publié peut obtenir une exécution locale non privilégiée vers root sur les cibles prises en charge.

L'exploitabilité dépend de l'environnement et nécessite la configuration TUN/périphérique réseau pertinente ainsi que les fonctionnalités de support.

🧠 Flux technique

             ATTAQUANT
                 │
                 ▼
       Headroom réseau surdimensionné
                 │
                 ▼
        Périphérique réseau virtuel
                 │
                 ▼
             Open vSwitch
                 │
                 ▼
              TUN/TAP
                 │
                 ▼
          tun_get_user()
                 │
                 ▼
       SKB_MAX_HEAD(align)
                 │
                 ▼
          Underflow d'entier
                 │
                 ▼
          Débordement size_t
                 │
                 ▼
       Offset skb->data invalide
                 │
                 ▼
       Corruption mémoire du noyau

🔎 Chemin de code vulnérable

Les composants importants sont :

drivers/net/tun.c
        │
        ├── tun_set_headroom()
        │
        ├── tun_get_user()
        │
        └── tun_alloc_skb()

La relation vulnérable peut être simplifiée ainsi :

tun->align
    │
    ├── headroom skb
    │
    └── calcul des données linéaires

L'utilisation de la même valeur surdimensionnée dans les deux calculs crée une relation dangereuse entre le headroom demandé et le budget réel de la tête skb.

🧮 Underflow d'entier

La propriété de sécurité critique peut être représentée conceptuellement par :

usable_head < requested_headroom

ce qui peut entraîner :

SKB_MAX_HEAD(align) < 0

suivi d'une conversion non signée :

valeur négative
      ↓
size_t
      ↓
valeur non signée très grande

Cela peut finalement influencer l'allocation/le placement des données skb.

La description officielle note spécifiquement que la valeur résultante déborde lorsqu'elle est assignée à la variable size_t linear.

🩹 Correctif amont

Le correctif amont est :

447c9303942c439a117d9b76ce6d6e2116c38ee7

Commit :

net: tun: bound receive headroom

Le correctif borne le headroom stocké par TUN par rapport au budget disponible de tête skb d'une page et au plus grand offset d'en-tête skb valide sur 16 bits. Il garantit également que suffisamment de données linéaires sont disponibles pour le traitement TUN et TAP brut.

🛡️ Concept du correctif

Avant

Utilisateur / périphérique réseau
        │
        ▼
Grand headroom
        │
        ▼
tun->align
        │
        ▼
Arithmétique dangereuse
        │
        ▼
Accès OOB potentiel

Après

Utilisateur / périphérique réseau
        │
        ▼
Grand headroom
        │
        ▼
Headroom borné
        │
        ▼
Calcul skb sûr
        │
        ▼
Traitement normal des paquets

📊 Vulnérable vs corrigé

🧪 Environnement de recherche

Topologie de laboratoire recommandée :

┌─────────────────────────────────────────┐
│             VM Linux / Hôte             │
│                                         │
│   ┌─────────┐     ┌──────────────┐     │
│   │ Netkit  │────▶│    VXLAN     │     │
│   └─────────┘     └──────┬───────┘     │
│                          │             │
│                   ┌──────▼───────┐     │
│                   │ Open vSwitch │     │
│                   └──────┬───────┘     │
│                          │             │
│                   ┌──────▼───────┐     │
│                   │    TUN/TAP   │     │
│                   └──────────────┘     │
│                                         │
└─────────────────────────────────────────┘

Outils utiles :

uname -a
ip link
ip tuntap
bridge link
ovs-vsctl show
dmesg -w

Pour le débogage du noyau :

GDB
GDB + GEF
GDB + pwndbg
crash
objdump
readelf
pahole

🔎 Vérification du noyau

Vérifier le noyau en cours d'exécution :

uname -r

Vérifier la configuration du noyau :

grep CONFIG_TUN /boot/config-$(uname -r)

Configuration attendue :

CONFIG_TUN=y

ou :

CONFIG_TUN=m

Vérifier si le module est chargé :

lsmod | grep tun

🧪 Recherche PoC

La divulgation publique fournit un dépôt PoC TUNderflow dédié pour une validation contrôlée.

Pour un flux de recherche sûr :

1. Compiler le noyau vulnérable
2. Démarrer une VM isolée
3. Configurer TUN/TAP
4. Reproduire le headroom surdimensionné
5. Surveiller les messages du noyau
6. Capturer le comportement de crash/corruption
7. Appliquer le correctif amont
8. Répéter le test
9. Comparer les résultats

Surveiller le noyau :

sudo dmesg -w

L'objectif du laboratoire est de démontrer la différence entre le comportement vulnérable et corrigé plutôt que d'attaquer des systèmes de production.

📂 Structure du dépôt

CVE-2026-81000-TUNderflow/
│
├── README.md
│
├── exploit/
│   ├── poc.c
│   └── Makefile
│
├── analysis/
│   ├── root-cause.md
│   ├── kernel-path.md
│   ├── integer-underflow.md
│   └── patch-analysis.md
│
├── kernel/
│   ├── vulnerable/
│   └── patched/
│
├── lab/
│   ├── setup.sh
│   ├── cleanup.sh
│   └── topology.md
│
├── screenshots/
│
├── docs/
│   └── research-notes.md
│
└── LICENSE

🔐 Atténuation

L'atténuation recommandée consiste à installer un noyau contenant le correctif de sécurité amont ou un backport approprié de la distribution.

Pour Debian/Kali :

sudo apt update
sudo apt full-upgrade

Puis redémarrer :

sudo reboot

Vérifier :

uname -r

Pour les environnements de production, vérifiez le noyau de distribution installé par rapport à l'avis de sécurité du fournisseur plutôt que de vous fier uniquement au numéro de version amont.

Oracle Linux, par exemple, a publié des mises à jour de sécurité contenant le correctif net: tun: bound receive headroom.

📦 Correctifs des noyaux stables

La divulgation publique identifie les versions de noyaux stables suivantes comme les premières versions contenant les correctifs pour les quatre vulnérabilités de root local divulguées, y compris TUNderflow :

🧩 Leçons de sécurité

TUNderflow démontre plusieurs principes importants de sécurité du noyau :

01 — Borner les valeurs influencées de l'extérieur

Les valeurs de configuration réseau ne doivent jamais être aveuglément approuvées.

02 — Valider l'arithmétique avant l'allocation

Un underflow d'entier peut transformer un calcul apparemment inoffensif en primitive de sécurité mémoire.

03 — Séparer les métadonnées des hypothèses mémoire

Une valeur de headroom de périphérique réseau doit rester cohérente avec le budget mémoire skb réel.

04 — Les piles réseau complexes augmentent la surface d'attaque

Les couches réseau virtuelles peuvent propager des métadonnées de paquets inattendues à travers plusieurs sous-systèmes.

05 — L'analyse des correctifs compte

L'étude du correctif amont fournit souvent une compréhension plus claire de la vulnérabilité originale que l'examen du seul crash.

📚 Références

• CVE : CVE-2026-81000
• Composant : Noyau Linux TUN/TAP
• Fichier affecté : drivers/net/tun.c
• Fonction principale : tun_get_user()
• Correctif amont : 447c9303942c439a117d9b76ce6d6e2116c38ee7
• Correctif : net: tun: bound receive headroom
• Divulgation : Avis de sécurité du noyau Linux / oss-security

👤 Recherche