세 가지 방법으로 들어와서, 하나의 `ObfDereferenceObject` 경로로 나간다.

그렇다고 코드가 틀렸다는 뜻은 아니다. 이는 **불변식이 분산되어 있다**는 뜻이다 — 어떤 단일 함수도 *"이 객체는 지금 살아 있다"*는 사실을 소유하지 않는다. 따라서 정확성은 모든 호출자가 자신이 쥔 참조가 무엇이며 얼마나 오래 유효한지에 대해 동의하는 데 달려 있다. 분산된 불변식은 경쟁 조건이 사는 곳이다. 경쟁은 한 함수 안에서 볼 수 있는 논리 버그가 결코 아니기 때문이다. 그것은 두 함수에 걸쳐 유지되는 가정의 버그다.

그래서 `PWND`를 건드리는 모든 함수에 묻기 시작한 질문은 *"이 코드가 올바른가?"*가 아니라 다음과 같았다:

> **정확히 이 함수 본문이 몇 개의 명령어 간격으로 두 스레드에서 실행된다면, 어느 쪽이 틀린 것일까?**



## 3. 근본 원인

결함은 창 소멸 경로에서 **참조 해제와 객체 해체 사이의 검사 시점 / 사용 시점(time-of-check / time-of-use) 간극**이며, 동시에 핸들을 검증하는 소비자에 대한 적절한 동기화가 없는 상태에서 발생한다.

그 형태를 단순화하면:```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

할당된 블록이 그럴듯한 태그와 쓰레기 내용을 담고 있다면 **손상(corruption)** 을 가리킵니다. *해제된* 블록, 또는 특수 풀(special-pool)의 무접근 페이지에 있는 블록은 **수명 버그(lifetime bug)** — 객체가 죽은 후에도 포인터를 붙들고 있는 상황을 가리킵니다. 이것이 *"공격자가 여기에 썼다"*와 *"이 객체는 도달 가능했어서는 안 된다"* 사이의 차이이며, 힙 손상 보고서와 CWE-362 보고서의 차이이기도 합니다.

어느 쪽으로 결론을 내리기 전에 객체 유형을 교차 확인하세요. `PWND`는 알아볼 수 있는 형태를 갖고 있습니다. 장애가 발생한 메모리에 그 잔재가 여전히 남아 있다면, 거의 확실히 임의 덮어쓰기보다는 윈도우-수명(window-lifetime) 문제입니다.

### 인터리빙에 대한 실시간 커널 디버깅

특수 풀을 사용하더라도 레이스는 스케줄링 문제이며, **디버거는 스케줄링을 변경합니다.** 이것이 레이스 작업의 핵심적인 좌절감입니다. 측정 도구가 측정 대상 자체를 교란한다는 것입니다. 해체(teardown) 경로에 걸린 중단점은 겹치려는 두 스레드를 정확히 직렬화하며, 버그는 예의 바르게 사라져 버립니다.

이를 돌파하는 방법은 중단점으로 레이스를 잡으려는 시도를 멈추고 대신 다음을 수행하는 것입니다:

- **인위적으로 창(window)을 넓혀라** — 참조 해제와 해체 사이의 간격을 늘리는 것은 무엇이든 정상적인 스케줄링 속도에서도 충돌에 도달할 수 있게 만든다,
- **정밀도보다 충돌 시도 횟수를 늘려라** — 두 경로를 계속 실행하고 확률이 작업을 하게 만든다,
- **조건부 및 일회성 중단점을 사용하라** — 모든 진입점에서 중단하는 대신, 관심 있는 상태가 존재할 때만 작동하도록 한다,
- **장애 발생 후 스레드 상태와 스택에서 인터리빙을 확인하라** — 실시간으로 관찰하려고 하지 말고.

그 오류 자체는 일단 잡고 나면 화려하지 않습니다. 메시지 디스패치 경로에서 `PWND`를 역참조하는 것인데, 그 객체는 이미 다른 스레드에서 해체를 거쳤고, `!pool`은 블록이 덮어쓰여진 것이 아니라 해제되었음을 확인해 줍니다:```
kd> !analyze -v

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