Vulnerability Classes
Every kernel exploit begins with a bug, and every bug belongs to a class. Once attacker-controlled input crosses the user/kernel boundary through an attack surface, something has to go wrong inside the driver for that input to become dangerous. The vulnerability class describes what goes wrong: a size that is not checked, a pointer that outlives its object, a value that is read twice from memory the attacker controls. Understanding these classes is not just taxonomy for its own sake. It shapes how you read patches, where you focus during code review, and which AutoPiff rules you write.
The landscape is not uniform. Some classes, like buffer overflow and use-after-free, dominate the CVE record because they arise naturally from the way C code manages memory and because the Windows pool allocator makes them reliably exploitable. Others, like logic bugs, are rarer in CVE counts but disproportionately impactful when they appear, since they bypass memory safety mitigations entirely. TOCTOU/double-fetch bugs occupy a middle ground: they require a race to trigger, which sounds unreliable until you realize that modern multi-core processors make the race winnable on almost every attempt.
The diagram below traces the path from initial trigger to exploitation primitive. A single trigger condition (say, an unchecked size field) can flow through different corruption types depending on context, and each corruption type yields a different primitive. This is why the same IOCTL handler bug might be classified as an integer overflow by one analyst and a buffer overflow by another; both are correct, because the integer overflow causes the buffer overflow. The classes are not mutually exclusive. They are lenses.
FIG_004 — Bug to Primitive Flow
Each trigger condition leads to a corruption type, which yields a specific exploitation primitive.
How to read this section
Each vulnerability class page follows a consistent structure. It opens with the mechanics of how the bug class arises in real driver code, then walks through exploitation implications and the primitives an attacker gains. Detection strategies cover both manual approaches and AutoPiff rule references, so you can connect the theory to tooling immediately.
The classes are ordered roughly by exploitation frequency in the Windows kernel CVE record, but they are deeply interconnected. An integer overflow produces a buffer overflow. A race condition produces a use-after-free. A TOCTOU bypasses a bounds check and enables a pool overflow. Reading across classes, rather than treating each in isolation, is how you develop intuition for the patterns that actually appear in Patch Tuesday diffs.
Categories
| Class | Description | Typical Primitive | Key CVEs |
|---|---|---|---|
| Buffer Overflow | Stack and heap buffer overflows | Pool Overflow, Pool Spray | CVE-2024-30085, CVE-2023-28252 |
| Integer Overflow | Integer overflow/underflow | Undersized alloc → Pool Overflow | CVE-2024-38063, CVE-2024-38054 |
| Type Confusion | Object type misinterpretation | Write-What-Where | CVE-2023-36802, CVE-2022-21882 |
| TOCTOU / Double-Fetch | Time-of-check-to-time-of-use | Depends on raced field (size → overflow, ptr → ARW) | CVE-2024-30088, CVE-2024-38106 |
| Use-After-Free | Dangling pointer dereference | Pool Spray reclaim | CVE-2024-38193, CVE-2023-29336 |
| Race Conditions | Concurrency and synchronization | UAF, double-free, state corruption | CVE-2024-38106, CVE-2024-30089 |
| Uninitialized Memory | Kernel memory disclosure | KASLR bypass via leaked pointers | CVE-2023-32019, CVE-2024-38256 |
| Arbitrary R/W Primitives | Patterns yielding arb R/W | Direct IOCTL R/W | CVE-2024-21338, CVE-2023-21768 |
| NULL Deref | NULL pointer dereference | DoS (BSOD), legacy code exec | CVE-2024-35250 |
| Logic Bugs | Design-level logic errors | Direct privilege escalation | CVE-2024-26229, CVE-2024-21302 |
The interplay between classes
One of the most important things to internalize is that vulnerability classes rarely exist in isolation during real exploitation. A typical Patch Tuesday CVE might involve an integer overflow that causes an undersized pool allocation, which leads to a heap buffer overflow, which corrupts an adjacent object's function pointer. That is three vulnerability classes collaborating in a single exploit chain. The case studies section traces these chains in detail, showing how a trigger in one class flows through to a primitive via another.
Similarly, the boundary between race conditions and use-after-free is porous. Many UAF bugs are caused by races, and the race condition page covers the concurrency mechanics while the UAF page covers the memory reclamation exploitation. Reading both gives you the complete picture.