जब ValidateHwnd कोई गेट नहीं है: CVE-2026-54107 का मूल कारण

win32kfull.sys विंडो जीवनचक्र प्रबंधन में एक use-after-free — यह कैसे मिला, कैसे मैंने खुद को विश्वास दिलाया कि यह वास्तविक है, और शोधकर्ता के नज़रिए से MSRC प्रक्रिया वास्तव में कैसी दिखी।

लगभग सुबह के 2 बज रहे थे जब टार्गेट VM डीबगर के हार्टबीट का जवाब देना बंद करके ठीक उसी निर्देश पर ब्रेक में गिर गया जिसे मैं हफ्तों से बहस करते हुए सुलभ बता रहा था। न कोई assertion, न corrupted-pool stop — बल्कि message-dispatch पथ पर एक साधारण access violation, किसी ऐसी ऑब्जेक्ट को dereference करते हुए जिसे दूसरे थ्रेड ने पहले ही तोड़ दिया था।

वह ब्रेक CVE-2026-54107, MSRC केस 11xxxxx, जुलाई 2026 सुरक्षा अपडेट में 27 Windows उत्पादों में पैच किया गया, बन गया।

यह पोस्ट कहानी का गैर-एम्बार्गो वाला आधा हिस्सा है: मूल कारण, यह बग श्रेणी क्यों ऐसी है, और वह तर्क जिसने मुझे वहाँ पहुँचाया। एक्सप्लॉइटेशन से जुड़े विवरण शामिल नहीं हैं।

विषय-सूची

• 1. win32k क्यों, और विशेष रूप से window ऑब्जेक्ट्स क्यों
• 2. वह गंध जिसने मुझे रोक दिया
• 3. मूल कारण
• 4. प्रभाव रेटिंग जो है वैसी क्यों है
• 5. सबसे पहले खंडन किया गया — अधिकांश उम्मीदवार अस्वीकार हो गए
• 6. सत्यापन: स्थैतिक परिकल्पनाएँ देता है, डीबगर सत्य देता है
• 7. कर्नेल शोध में AI का उपयोग करने पर
• 8. MSRC टाइमलाइन, ईमानदारी से
• 9. स्नैपशॉट
• 10. शुरुआत करने वाले किसी को मैं क्या बताऊँगा
• 11. आगे क्या

1. win32k क्यों, और विशेष रूप से window ऑब्जेक्ट्स क्यों

Win32k, Windows ग्राफ़िकल सबसिस्टम का kernel-mode भाग है। यह पुराना है, बहुत बड़ा है, और — महत्वपूर्ण रूप से — यह उन संदर्भों से पहुँच योग्य है जिन्हें अविश्वसनीय माना जाता है। यह अंतिम गुण ही कारण है कि बीस साल के hardening, filtering और syscall प्रतिबंध कार्यों के बावजूद यह स्थायी शोध लक्ष्य बना हुआ है।

win32k के भीतर, tagWND ऑब्जेक्ट (PWND) असामान्य रूप से दिलचस्प है क्योंकि इसका जीवनकाल एक साथ एक से अधिक तंत्रों द्वारा प्रबंधित होता है। एक window:

• हैंडल द्वारा संदर्भित, यूज़र हैंडल टेबल और ValidateHwnd-शैली लुकअप के माध्यम से,
• पॉइंटर द्वारा संदर्भित, nested कॉल्स और message dispatch के दौरान रखा गया,
• अप्रत्यक्ष रूप से संदर्भित parent/child, owner/owned, और thread/desktop संबंधों द्वारा,
• और एक विनाश पथ के माध्यम से तोड़ा गया, जिसे उपरोक्त सभी को सही क्रम में उलटना होता है।

कई स्वतंत्र संदर्भ पथों और एक साझा विनाश पथ वाली कोई भी ऑब्जेक्ट धीरे-धीरे पढ़ने लायक है। यह कोई vulnerability दावा नहीं है — यह एक heuristic है कि समय कहाँ बिताना है।

2. वह गंध जिसने मुझे रोक दिया

इस कंपोनेंट पर मुझे रोकने वाली चीज़ import surface थी। win32kfull.sys ntoskrnl से तीन अलग-अलग ऑब्जेक्ट संदर्भ primitives खींचता है:```c NTSTATUS ObReferenceObjectByPointer( void *Object, uint32_t DesiredAccess, POBJECT_TYPE ObjectType, char AccessMode);

NTSTATUS ObReferenceObjectByHandle( HANDLE Handle, uint32_t DesiredAccess, POBJECT_TYPE ObjectType, char AccessMode, void **Object, OBJECT_HANDLE_INFORMATION *HandleInformation);

NTSTATUS ObReferenceObjectByName(/* ... */);

अंदर जाने के तीन पथ, बाहर निकलने का एक `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      */
    }
}

No input content was provided after "INPUT:". Please provide the chunk text to translate.```c /* Thread B — consumer, concurrent / NtUserMessageCall(HWND hwnd, UINT msg, ...) { PWND pWnd = ValidateHwnd(hwnd); / may resolve a handle whose object is mid-teardown */

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."