Drei Wege hinein, ein `ObfDereferenceObject`-Pfad hinaus.

Das bedeutet nicht, dass der Code falsch ist. Es bedeutet, dass die **Invariante verteilt ist** — keine einzelne Funktion besitzt *"dieses Objekt ist jetzt gerade lebendig,"* daher hängt die Korrektheit davon ab, dass jeder Aufrufer sich darüber einig ist, welche Referenz er hält und wie lange sie gültig ist. Verteilte Invarianten sind der Ort, an dem Race Conditions leben, denn eine Race ist niemals ein Logikfehler, den man in einer einzelnen Funktion sehen kann. Es ist ein Fehler in einer Annahme, die über zwei hinweg gehalten wird.

Also war die Frage, die ich jeder Funktion, die ein `PWND` berührte, zu stellen begann, nicht *"ist dieser Code korrekt?"*, sondern:

> **Wenn dieser exakte Funktionsrumpf auf zwei Threads im Abstand weniger Anweisungen ausgeführt wird, welcher von ihnen ist falsch?**



## 3. Grundursache

Der Defekt ist eine **Time-of-Check/Time-of-Use-Lücke zwischen Referenzfreigabe und Objektabbau** im Fensterzerstörungspfad, ohne ausreichende Synchronisation mit einem gleichzeitigen Konsumenten, der Handles validiert.

Auf seine Grundform reduziert:```c
/* Thread A — teardown */
NtUserDestroyWindow(HWND hwnd)
{
    PWND pWnd = ValidateHwnd(hwnd);
    if (pWnd) {
        ObfDereferenceObject(pWnd);   /* reference released */

        /* <-- race window: object may become reclaimable here */

        FreeWindowObject(pWnd);       /* teardown proceeds on a pointer
                                         no longer guaranteed live      */
    }
}

if (pWnd->fnid == FNID_BUTTON)    /* use-after-free */
    ...

Two things have to be true for this to matter, and both were:

**(a) The window is real.** `ValidateHwnd` is the gate that's supposed to make handle-based access safe. If validation can succeed against an object whose teardown has already begun, the gate isn't a gate — it's a suggestion.

**(b) The freed memory is attacker-influenceable.** The fields read immediately after validation include `fnid`, which drives message dispatch. A dispatch decision made from reclaimed memory is the difference between *"unreliable crash"* and *"security boundary violation."* That distinction is the entire reason this is CWE-362 with EoP impact and not a stability bug.

> The observed **corruption** is a use-after-free; the **cause** is CWE-362, concurrent execution using a shared resource with improper synchronization. Those are two different statements and MSRC cares about the second one. **Report the cause, not just the symptom.**

### Why win32k races are structurally harder than they look

If you've raced bugs in other subsystems, win32k will frustrate you, because the architecture fights you in three specific ways.

**Windows have thread affinity.** A window belongs to the thread that created it. A lot of the subsystem is built around the assumption that the owning thread is the one touching the object, which means the naive "spin two threads calling the same API" approach frequently doesn't overlap anything — you're not racing, you're queueing. Getting two paths to genuinely collide on the same object requires understanding which operations actually execute on the caller's thread versus which get marshalled to the owner's.

**Message dispatch partially serializes you.** Sends and posts behave differently, and cross-thread versus same-thread dispatch behave differently again. Some of what looks like a concurrency opportunity is silently converted into an ordered operation before it ever reaches the code you care about. If you don't know which category your trigger falls into, you'll conclude a real race is unreachable — a false negative that looks identical to "no bug here."

**The critical section hides in the caller.** Much of the subsystem runs under a coarse lock acquired well above the function you're staring at. This is the single biggest source of wasted time in win32k auditing: a function with no visible synchronization that is nonetheless perfectly safe because every path into it is already serialized. **Lock coverage is an interprocedural property.** You must walk up the call graph, not just read the function.

That third point is why *"no lock in this function"* is worth almost nothing as a signal, and why most of the work in this hunt was spent on reachability rather than on the defect itself.


## 4. Why the impact rating is what it is

MSRC assessed this as **Important, Elevation of Privilege, CVSS 8.8, attack vector local, authenticated.** Two properties drive that:

**Reachability from low integrity.** Win32k message-call surface is reachable from contexts far below SYSTEM. That's what makes it relevant to sandbox-escape chains — a renderer process that has already achieved code execution inside its sandbox can still reach this surface. A kernel bug's severity is mostly a function of *who can touch it*, not how clever the corruption is.

**Dispatch-influencing corruption.** Corrupting a field that a `switch` runs on is qualitatively worse than corrupting a field that only gets logged. The former turns a memory bug into a control-flow question.

I want to be precise about something here, because I've seen first-CVE posts overstate this: **I demonstrated the race and the use-after-free. I did not ship a weaponized SYSTEM-level exploit.** The sandbox-escape framing describes the *class of chain* this bug type belongs to and why the surface is valuable — it is an argument about reachability, not a claim that I built one. Overclaiming impact is the fastest way to burn credibility with a vendor, and MSRC's assessment is the number that matters, not mine.



## 5. Falsification came first — most candidates died

The part nobody writes about: this was not the first candidate. It was the one that survived.

My working rule is that **a candidate is guilty until proven guilty.** Every promising pattern gets a specific, written-down reason it *shouldn't* be exploitable, and I go try to establish that reason before I go try to trigger it. Candidates I closed before this one included:

- paths that looked unsynchronized but were serialized by a lock acquired one frame up,
- paths where the "freed" object was actually cached rather than released,
- paths that were genuinely racy but not reachable from any caller a low-privilege user could drive.

Every one of those is a finding I *did not* send to MSRC. That's the point. A researcher's throughput isn't how many candidates they generate — it's how fast they can kill the wrong ones so they're not still holding them at 2 AM.

**The three questions that killed most candidates:**

1. **Is anything above me holding a lock?** Interprocedural, not local. The absence of a lock in a function means nothing.
2. **Can an unprivileged caller actually reach both sides?** A race between two paths that require different privilege levels isn't a race, it's a thought experiment.
3. **Is the freed memory reclaimable in a window I can influence?** If teardown completes atomically for practical purposes, there's no bug worth reporting.



## 6. Verification: static gives hypotheses, the debugger gives truth

Static analysis of `win32kfull.sys` gave me the hypothesis. It could never give me the bug. **Race conditions aren't visible in a decompiler** because the defect isn't in the instructions — it's in the interleaving.

### Lab

| Role | Setup |
| --- | --- |
| Host / debugger | Windows 11, WinDbg |
| Target | Windows Server 2022, Build 20348.2159 |
| Analysis | Kali Linux + Windows 11 VM |
| Debug transport | VMware serial COM, host → target kernel debugging |
| Static analysis | Ghidra via GhidraMCP |
| Triage assist | AI-assisted pass over decompiled output |

Three instrumentation layers did the actual work.

### Special pool and Driver Verifier

The single highest-leverage step in any kernel UAF investigation. By default, freed pool memory is reused almost immediately by the next allocation of a similar size — which means a use-after-free usually *doesn't fault*. It reads someone else's valid data, keeps executing, and detonates somewhere unrelated minutes later. You then spend three days auditing an innocent function.

Special pool changes that. Each allocation gets its own page with a guard page adjacent, and freed pages are marked no-access rather than recycled. The result is that the offending dereference faults **at the instruction that performs it**, not downstream:```
!verifier 0x1 win32kfull.sys        ; special pool on the target driver
!verifier 0x8 win32kfull.sys        ; pool tracking

Ein Block, der mit einem plausiblen Tag und Müll-Inhalt *zugewiesen* ist, deutet auf **Korruption** hin. Ein Block, der *freigegeben* ist oder in einer No-Access-Seite eines Special-Pools liegt, deutet auf einen **Lebensdauerfehler** hin — etwas hat einen Zeiger über den Tod des Objekts hinaus gehalten. Genau das ist der Unterschied zwischen *„Angreifer hat hier geschrieben“* und *„Dieses Objekt hätte nicht erreichbar sein dürfen,“* und er ist der Unterschied zwischen einer Heap-Korruptionsmeldung und einer CWE-362-Meldung.

Überprüfe den Objekttyp, bevor du dich für eine der beiden Möglichkeiten entscheidest. Ein `PWND` hat eine erkennbare Form; wenn der Speicher, an dem der Zugriffsfehler aufgetreten ist, noch die Überreste eines solchen trägt, befindest du dich fast sicher in einem Problem im Lebensdauerfenster und nicht in einer zufälligen Überschreibung.

### Live-Kernel-Debugging bei der Verschachtelung

Selbst mit Special Pool ist ein Wettlauf ein Scheduling-Problem, und **der Debugger verändert das Scheduling.** Das ist der zentrale Frust bei der Arbeit an Wettläufen: Das Instrument stört das, was es misst. Ein Haltepunkt im Teardown-Pfad serialisiert genau die beiden Threads, die du zu überlappen versuchst, und der Bug verschwindet höflich.

Der Ausweg besteht darin, nicht mehr zu versuchen, den Wettlauf mit einem Haltepunkt zu fangen, und stattdessen:

- **das Fenster künstlich vergrößern** — alles, was das Intervall zwischen Referenzfreigabe und Teardown verlängert, macht die Kollision bei normalen Scheduling-Raten erreichbar,
- **eher Kollisionsversuche als Präzision erhöhen** — die beiden Pfade kontinuierlich ausführen und die Wahrscheinlichkeit die Arbeit erledigen lassen,
- **bedingte und einmalige Haltepunkte verwenden**, die sich erst aktivieren, wenn der interessante Zustand existiert, anstatt bei jedem Eintritt zu unterbrechen,
- **die Verschachtelung nach dem Fehler bestätigen**, anhand des Thread-Zustands und der Stacks, anstatt zu versuchen, sie live zu beobachten.

Der Fehler selbst ist, sobald du ihn hast, unspektakulär — eine Dereferenzierung eines `PWND` auf dem Nachrichtenverteilungspfad, auf dem das Objekt bereits auf einem anderen Thread den Teardown durchlaufen hat, wobei `!pool` bestätigt, dass der Block freigegeben und nicht überschrieben wurde:```
kd> !analyze -v

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Access violation
FAULTING_MODULE: win32kfull