Driver Types
When you sit down to audit a Windows kernel driver, the first question is not "where is the bug?" but "what kind of driver is this?" The answer shapes everything that follows: which system calls reach it, what objects it manages, what memory it touches, and which exploitation primitives are realistic once you find a flaw. A heap overflow in a file system driver that parses on-disk metadata is a fundamentally different research target than a logic bug in a vendor utility driver that hands you physical memory read/write by design.
KernelSight organizes kernel drivers into twelve categories based on their role in the Windows kernel architecture. Each category carries distinct IRP handling patterns, accessible attack surfaces, and historical vulnerability profiles. A driver's category predicts its bug classes with surprising consistency: CLFS drivers produce pool corruptions from metadata parsing, Win32k drivers produce use-after-free and type confusion from object lifecycle complexity, and vendor utility drivers produce arbitrary read/write from intentional design choices that were never meant to face adversarial callers. Understanding these patterns before you start reversing saves weeks of unfocused analysis.
FIG_002 — Windows Kernel Architecture
Driver types positioned within their kernel subsystem. CVE counts from the KernelSight corpus.
Categories
| Driver Type | Examples | CVEs in Corpus | Key Attack Surface |
|---|---|---|---|
| File System Drivers | ntfs.sys, fastfat.sys | 2 | On-disk structure parsing, IRP dispatch |
| File System Minifilters | cldflt.sys | 2 | Pre/post-operation callbacks, reparse data |
| Log / Transaction Drivers | clfs.sys | 4 | Metadata parsing, base log manipulation |
| Network Stack | tcpip.sys, afd.sys, http.sys | 5 | Packet parsing, socket operations, protocol handling |
| Kernel Streaming | ks.sys, mskssrv.sys, ksthunk.sys | 5 | IOCTL dispatch, WOW64 thunking, MDL operations |
| Win32k Subsystem | win32k.sys, win32kbase.sys, win32kfull.sys | 3 | Syscall handlers, GDI objects, window management |
| Core Kernel | ntoskrnl.exe | 4 | Syscall handlers, security subsystem, VBS |
| Security / Policy Drivers | appid.sys | 1 | IOCTL access control, policy enforcement |
| Storage / Caching Drivers | csc.sys | 1 | IOCTL handlers, file caching |
| Vendor Utility | DBUtil, RTCore64, gdrv, iqvw64e, HW.sys, ATSZIO64, AsIO3, WinRing0, etc. | 14 | Physical memory R/W, MSR access, I/O port |
| Performance & GPU | AMDRyzenMasterDriver.sys, ThrottleStop.sys, nvlddmkm.sys | 4 | MSR write, GPU memory mapping, MMIO |
| Third-Party Security | Capcom.sys, echo_driver.sys, viragt64.sys, Truesight.sys, amsdk.sys | 5 | Ring-0 exec, callback manipulation, process termination |
Browse by Driver Type
Driver Type vs. Vulnerability Class Heatmap
| Driver Type | Buffer Overflow | Integer Overflow | Type Confusion | Race Condition | UAF | Info Disclosure | Logic Bug |
|---|---|---|---|---|---|---|---|
| File System | ■■ | ■ | |||||
| Minifilter | ■■ | ||||||
| Log / Transaction | ■■■■ | ||||||
| Network Stack | ■ | ■■ | ■ | ||||
| Kernel Streaming | ■ | ■ | ■ | ||||
| Win32k | ■ | ■ | ■ | ||||
| Core Kernel | ■■ | ■ | ■ | ||||
| Security / Policy | ■ | ||||||
| Storage / Caching | ■ | ||||||
| Vendor Utility | ■■■■■■■■■■■■■■ | ||||||
| Performance & GPU | ■ | ■■■ | |||||
| Third-Party Security | ■■■■■ |
The heatmap above reveals a pattern worth studying. Microsoft's own kernel components cluster around memory corruption bugs: buffer overflows, integer overflows, type confusions, and use-after-free. Third-party and vendor drivers cluster around logic bugs, because their "vulnerability" is typically an intentional design choice (physical memory access, MSR writes, process termination IOCTLs) exposed without adequate access control. These two clusters demand different research approaches. Memory corruption bugs require deep binary analysis and patch diffing. Logic bugs require understanding the driver's intended functionality and asking "who else can call this?"
The Attack Surfaces section explores how user-mode code actually reaches each of these driver types.