This fixes an out-of-bounds access in the WebAssembly BBQ JIT (64-bit) because the array bounds check compared only the low 32 bits of the index while the element address used the full 64-bit register. In BBQJIT::addArrayGet and addArraySet, the index is bounds-checked with a 32-bit compare — branch32(AboveOrEqual, indexGPR, array->size) — but the index register can hold a 64-bit value whose upper 32 bits are non-zero. Pre-patch the code proceeded to compute the element address from the full 64-bit register, so an index such as 0x7fffffff00000000 passes the 32-bit check (low 32 bits = 0 < size) yet the actual access uses the full 64-bit value as the offset, reading or writing far outside the array — an out-of-bounds memory access.

The fix inserts m_jit.zeroExtend32ToWord(indexGPR, indexGPR) immediately after the bounds check in both addArrayGet and addArraySet, clearing the upper 32 bits so the access uses only the validated low 32 bits.

The restored invariant is that the index used for the element address matches the 32-bit value that was bounds-checked. The regression test passes 0x7fffffff00000000n to a wasm array access.

A controllable out-of-bounds read/write in the WebContent process via WebAssembly array access — the attacker chooses the high bits of the index, giving a strong, wide-reaching corruption primitive and a well-known route toward arbitrary read/write and code execution.