Firefox SpiderMonkey WebAssembly GC RCE: One Typo, Full Renderer Compromise

Technical Deep Dive: One Character, Maximum Damage

The Guilty Commit

Everything traces back to a single refactoring commit — fcc2f20e35ec — which modified the handling of WebAssembly GC array metadata in js/src/wasm/WasmGcObject.cpp. The commit was supposed to store a tagged forwarding pointer (with the LSB set to 1) when the GC moves an Out-of-Line (OOL) Wasm array. The code was written like this:

oolHeaderOld->word = uintptr_t(oolHeaderNew) & 1;

It should have been:

oolHeaderOld->word = uintptr_t(oolHeaderNew) | 1;

The difference is a single character: & (AND) instead of | (OR). The intent of the original code, as the accompanying comment explicitly states, was to set bit 0 of the forwarding pointer — the classic "tagged pointer" trick to distinguish a forwarding address from a real header value. Using | 1 achieves this by setting the LSB. Using & 1 does the opposite: since all heap pointers are at minimum 8-byte aligned, uintptr_t(oolHeaderNew) & 1 is always 0. The code faithfully writes a zero word into the old buffer header instead of a tagged forwarding pointer.

SpiderMonkey's OOL vs. Inline Array Architecture

To understand why this matters, it helps to understand how SpiderMonkey stores WebAssembly GC arrays. Firefox's SpiderMonkey implements the Wasm GC proposal, which supports garbage-collected array types. For small arrays (zero to ~32 bytes), element data is stored inline (IL) immediately after the WasmArrayObject header — no separate allocation needed. For larger arrays, SpiderMonkey allocates a separate out-of-line (OOL) block managed by js::gc::BufferAllocator.

Critically, SpiderMonkey distinguishes between these two layouts at runtime by examining the LSB of the header word:

static inline bool isDataInline(uint8_t* data) {
  const OOLDataHeader* header = (OOLDataHeader*)data;
  header--;
  uintptr_t headerWord = header->word;
  return (headerWord & 1) == 0;  // LSB=0 means Inline; LSB=1 means OOL forwarding pointer
}

With the typo in place, when the GC moves an OOL array, it writes 0 into the old buffer's header. The old buffer now passes isDataInline() — LSB is 0 — so SpiderMonkey believes the old OOL block is an inline array. This is a type confusion: the engine reads array elements from an address derived from inline layout arithmetic, but the memory region belongs to a completely different allocation. The result is controlled out-of-bounds read/write, which is the foundation of a reliable exploitable primitive.

The Exploitable Condition

Two constraints narrow the attack surface slightly:

1. The bug is only triggerable in code paths optimized by Ion, SpiderMonkey's advanced JIT compiler. It does not occur in the Baseline compiler. This means the Wasm function must be sufficiently "hot" to trigger Ion compilation — typically a few hundred to a thousand iterations. This is trivially achievable by any attacker-controlled webpage.
2. The GC must physically move the OOL array — either Nursery→Nursery or Nursery→Tenured. This requires a minor GC to fire during or between Wasm executions. Again, trivially achievable: attackers can allocate memory to force GC pressure, and modern Wasm-heavy pages do this naturally.

The researcher's PoC from the disclosure demonstrates a reliable crash within seconds using a 128-element Wasm byte array, an explicit minorgc(true) call between each iteration, and a 1000-iteration warm-up loop. Real exploits would not need the explicit GC call — allocation pressure from the array creation loop alone would trigger the necessary GC cycles.

From Type Confusion to RCE

Once the type confusion is established — OOL array treated as IL — the attacker controls which memory region is interpreted as the array's element storage. A standard WebAssembly array read or write operation then becomes an arbitrary read or write primitive at an attacker-controlled address. The path from here to full RCE in the renderer process follows well-established browser exploitation patterns:

1. Leak heap address: Use the confusion primitive to read a known structure, obtaining a heap layout reference point
2. Corrupt JIT code or function pointer: Overwrite a code pointer in a nearby JIT-compiled function or a vtable entry in a Wasm object
3. Redirect execution: Trigger the corrupted function, gaining PC control
4. ROP chain / shellcode: Standard renderer code execution from this point

The researcher confirmed achieving code execution in the Firefox renderer process. The renderer is sandboxed (Firefox uses process isolation), so a full system compromise would additionally require a sandbox escape — but renderer RCE alone gives attackers access to all content in the compromised tab, including credentials, session cookies, and sensitive form data.

Attack Tools for Security Researchers

Understanding and testing browser vulnerabilities like this one benefits enormously from dedicated tooling. For Wasm fuzzing and JavaScript engine research, Burp Suite Professional provides essential proxy and interception capabilities for analyzing how Wasm modules are served and executed. The The Browser Hacker's Handbook by Wade Alcorn et al. covers the full spectrum of browser exploitation techniques, including memory corruption in JavaScript engines — essential background for understanding SpiderMonkey internals. For hands-on lab work, a dedicated test machine running a vulnerable Firefox build is strongly recommended over your main browser.