BaseCompiler::emitArrayFill compiled the array.fill operation by emitting a fill loop that used numElements as a countdown loop variable, but it entered that loop without first calling sync() to reconcile the abstract value stack with the physical register/stack state. Because the loop contains a control-flow join (the done label and the back-edge) and manipulates registers such as PreBarrierReg, the baseline compiler’s invariant that operand-stack values held in registers are spilled before branch targets was violated, so the compiler’s model of where operands lived diverged from the code actually generated. This let generated code read or write the wrong registers/stack slots across the loop boundary, corrupting engine state.

The fix adds a single sync() call immediately before the fill loop is emitted, forcing all live register-resident stack values to be flushed so the machine state is consistent at the loop’s control-flow join. With the spill in place the loop’s back-edge and exit see a well-defined stack layout, restoring the compiler’s core register-allocation invariant.

An attacker who lures a victim to a malicious web page can drive the WASM baseline compiler into producing miscompiled array.fill code, yielding memory corruption inside the sandboxed content process where SpiderMonkey runs. The metadata rates this critical and notes public exploit code exists; preconditions are only that WebAssembly GC compilation via the baseline tier is reachable and the crafted module is executed. No special privileges or user interaction beyond visiting the page are indicated by the diff.