The vulnerable code path was the widening WebAssembly GC field-load MIR op (a WasmLoad*KA-style node carrying wideningOp: wasm::FieldWideningOp and result_type: Int32) as declared in MIROps.yaml. That op was marked movable: true while also declaring alias_set: none and congruent_to: if_operands_equal, which told the optimizer the load was a pure, memory-independent computation. In reality the op reads a packed (i8/i16) field out of a GC-managed struct or array, so its result depends on program order relative to stores into that field and on the point at which the containing object is valid. Because the load was treated as pure, GVN could common two such loads that straddle a store, and LICM could hoist the load out of a loop or above the store that defines its value — a code-generation logic error that yields a stale or incorrect widened value.

The fix removes the single movable: true line, so the load is no longer eligible for that motion or deduplication and stays pinned to its original data- and control-flow position.

An attacker gains an incorrect-codegen bug that reliably crashes and may be leveraged into memory corruption and code execution inside the content process that runs the wasm. Exploitation requires only that the victim load attacker-controlled content that delivers a WebAssembly GC module and drives the function into the JIT’s optimizing tier; no elevated privileges are needed, though escaping the sandbox would require a further step.