अंदर जाने के तीन पथ, बाहर निकलने का एक `ObfDereferenceObject` पथ।

इसका मतलब यह नहीं है कि कोड गलत है। इसका मतलब है कि **इनवेरिएंट वितरित है** — कोई एक फ़ंक्शन *"यह ऑब्जेक्ट अभी जीवित है"* का स्वामी नहीं होता, इसलिए शुद्धता इस पर निर्भर करती है कि हर कॉलर इस बात पर सहमत हो कि वे कौन सा रेफ़रेंस पकड़े हुए हैं और वह कितने समय तक मान्य है। वितरित इनवेरिएंट्स ही वे स्थान हैं जहाँ रेस कंडीशंस पनपती हैं, क्योंकि रेस कभी भी कोई लॉजिक बग नहीं होती जिसे आप किसी एक फ़ंक्शन में देख सकें। यह एक ऐसी धारणा में बग है जो दो के बीच साझा होती है।

तो जो सवाल मैंने हर उस फ़ंक्शन से पूछना शुरू किया जो `PWND` को छूता था, वह *"क्या यह कोड सही है?"* नहीं था, बल्कि:

> **यदि यही फ़ंक्शन बॉडी दो थ्रेड्स पर कुछ ही निर्देशों के अंतराल पर निष्पादित होती है, तो उनमें से कौन सा गलत है?**

## 3. मूल कारण

यह दोष window destruction path में **रेफ़रेंस रिलीज़ और ऑब्जेक्ट टियरडाउन के बीच time-of-check / time-of-use अंतराल** है, जिसमें समवर्ती handle-validating consumer के विरुद्ध पर्याप्त synchronization नहीं है।

इसके मूल स्वरूप में:```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

एक ब्लॉक जो *आवंटित* (allocated) है और उसमें एक संभावित टैग और कचरा कंटेंट है, **भ्रष्टाचार** (corruption) की ओर इशारा करता है। एक ब्लॉक जो *मुक्त* (freed) है, या किसी विशेष-पूल नो-एक्सेस पेज पर रखा हुआ है, **लाइफ़टाइम बग** की ओर इशारा करता है — यानी किसी पॉइंटर को ऑब्जेक्ट की मृत्यु के बाद भी पकड़े रखना। यही *"हमलावर ने यहाँ लिखा"* और *"यह ऑब्जेक्ट पहुँच योग्य नहीं होना चाहिए था"* के बीच का अंतर है, और यह हीप-भ्रष्टाचार रिपोर्ट और CWE-362 रिपोर्ट के बीच का अंतर है।

किसी निष्कर्ष पर पहुँचने से पहले ऑब्जेक्ट प्रकार को क्रॉस-चेक करें। एक `PWND` की पहचान योग्य आकृति होती है; यदि जिस मेमोरी पर आपको फॉल्ट मिला है, उसमें अभी भी उसके अवशेष मौजूद हैं, तो आप लगभग निश्चित रूप से एक विंडो-लाइफ़टाइम समस्या में हैं, न कि किसी यादृच्छिक ओवरराइट में।

### इंटरलीविंग पर लाइव कर्नेल डिबगिंग

स्पेशल पूल के साथ भी, एक रेस शेड्यूलिंग की समस्या है, और **डीबगर शेड्यूलिंग को बदल देता है।** रेस कार्य की यही केंद्रीय निराशा है: उपकरण उस चीज़ को विक्षुब्ध करता है जिसे वह मापता है। टियरडाउन पथ पर एक ब्रेकपॉइंट उन दो थ्रेड्स को सीरियलाइज़ कर देता है जिन्हें आप ओवरलैप करने की कोशिश कर रहे हैं, और बग विनम्रता से गायब हो जाता है।

इससे निकलने का रास्ता यह है कि ब्रेकपॉइंट से रेस को पकड़ने की कोशिश करना बंद करें और इसके बजाय:

- **विंडो को कृत्रिम रूप से चौड़ा करें** — जो भी रेफरेंस रिलीज़ और टियरडाउन के बीच के अंतराल को लंबा करता है, वह सामान्य शेड्यूलिंग दरों पर टक्कर को पहुँच योग्य बना देता है,
- **सटीकता के बजाय टक्कर के प्रयास बढ़ाएँ** — दोनों पथों को लगातार चलाएँ और संभावना को काम करने दें,
- **कंडीशनल और वन-शॉट ब्रेकपॉइंट्स का उपयोग करें** जो केवल तब सक्रिय होते हैं जब रुचिकर स्थिति मौजूद होती है, हर प्रविष्टि पर ब्रेक करने के बजाय,
- **फॉल्ट के बाद इंटरलीविंग की पुष्टि करें**, थ्रेड स्थिति और स्टैक्स से, लाइव इसे देखने की कोशिश करने के बजाय।

फॉल्ट स्वयं, एक बार मिल जाने पर, बहुत साधारण होता है — मैसेज-डिस्पैच पथ पर एक `PWND` का डीरेफ़रेंस जहाँ ऑब्जेक्ट पहले ही किसी अन्य थ्रेड पर टियरडाउन से गुज़र चुका है, और `!pool` यह पुष्टि करता है कि ब्लॉक ओवरराइट होने के बजाय रिलीज़ किया गया था:```
kd> !analyze -v

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