Três formas de entrada, um caminho de saída `ObfDereferenceObject`.

Isso não significa que o código esteja errado. Significa que o **invariante é distribuído** — nenhuma função individual é dona de *"este objeto está vivo agora"*, portanto a corretude depende de cada chamador concordar sobre qual referência ele detém e por quanto tempo ela é válida. Invariantes distribuídos são onde as condições de corrida moram, porque uma corrida nunca é um bug de lógica que você pode ver em uma única função. É um bug em uma suposição mantida entre duas.

Então a pergunta que comecei a fazer a toda função que tocava em um `PWND` não era *"este código está correto?"* mas sim:

> **Se exatamente este corpo de função for executado em duas threads com algumas instruções de diferença, qual delas está errada?**



## 3. Causa raiz

O defeito é uma **lacuna de tempo de verificação / tempo de uso entre a liberação da referência e a destruição do objeto** no caminho de destruição da janela, sem sincronização adequada contra um consumidor concorrente que valida handles.

Reduzido à sua forma:```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      */
    }
}

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

Um bloco que foi *alocado* com uma tag plausível e conteúdo de lixo aponta para **corrupção**. Um bloco que foi *liberado*, ou que está em uma página sem acesso do pool especial, aponta para um **bug de tempo de vida** — algo segurou um ponteiro além da morte do objeto. Essa é a distinção entre *"o atacante escreveu aqui"* e *"este objeto não deveria ter sido alcançável"*, e é a diferença entre um relatório de corrupção de heap e um relatório CWE-362.

Faça a verificação cruzada do tipo de objeto antes de se comprometer com qualquer um dos casos. Um `PWND` tem um formato reconhecível; se a memória onde a falha ocorreu ainda carrega os remanescentes de um, você está quase certamente diante de um problema de janela de tempo de vida, e não de uma sobrescrita aleatória.

### Depuração ao vivo do kernel na intercalação

Mesmo com o pool especial, uma corrida é um problema de agendamento, e **o depurador altera o agendamento.** Essa é a principal frustração do trabalho com corridas: o instrumento perturba aquilo que mede. Um breakpoint no caminho de teardown serializa exatamente as duas threads que você está tentando sobrepor, e o bug desaparece educadamente.

O caminho para contornar isso é parar de tentar capturar a corrida com um breakpoint e, em vez disso:

- **alargar a janela artificialmente** — qualquer coisa que prolongue o intervalo entre a liberação da referência e o teardown torna a colisão alcançável em taxas normais de agendamento,
- **aumentar as tentativas de colisão em vez da precisão** — execute os dois caminhos continuamente e deixe a probabilidade fazer o trabalho,
- **usar breakpoints condicionais e de disparo único** que só armam quando o estado interessante existe, em vez de parar em toda entrada,
- **confirmar a intercalação após a falha**, a partir do estado das threads e das pilhas, em vez de tentar observá-la ao vivo.

A falha em si, quando você a obtém, é sem glamour — uma desreferência de um `PWND` no caminho de despacho de mensagens em que o objeto já passou pelo teardown em outra thread, com `!pool` confirmando que o bloco foi liberado em vez de sobrescrito:```
kd> !analyze -v

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