The bug is in JavaScriptCore’s BBQ (Build Bytecode Quickly) tier of the WebAssembly JIT, specifically in BBQJIT::emitTailCall and BBQJIT::emitIndirectTailCall in Source/JavaScriptCore/wasm/WasmBBQJIT.cpp. In BBQ, every WebAssembly stack value is a Value object that owns a ‘binding’ to a concrete storage location (a specific GPR/FPR register or a stack slot), and the register allocator tracks those bindings; a value must be ‘consumed’ when its lifetime ends so its register/slot is released back to the allocator. A return_call / return_call_indirect / return_call_ref is a tail call: control never returns to the current frame, so all bytecode that textually follows it is unreachable. Before this patch, emitTailCall/emitIndirectTailCall emitted the far jump to the callee but did NOT consume the remaining entries of the parser’s expression stack (m_parser->expressionStack()). Those left-over Values kept their register/slot bindings alive across the tail call into the following unreachable region. When the validator/parser then processes that unreachable code (which WebAssembly still requires to be type-checked and which BBQ still walks), the stale bindings desynchronize the register allocator’s accounting from the actual expression-stack state, tripping a consistency assertion / RELEASE_ASSERT and crashing the process. The invariant violated is: at the point control leaves a frame for good, no expression-stack value may still hold a live binding into that frame’s register/slot file.

The fix restores the invariant by iterating m_parser->expressionStack() after emitting the tail-call jump and calling consume(value) on every element, releasing all bindings so the subsequent unreachable code starts from a clean allocator state. The provided reproducer exercises exactly this: return_call, return_call_indirect and return_call_ref are each placed inside a catch handler where the expression stack still carries partially-computed values (an i32.add result plus a live f32 local), so entries remain on the expression stack at the tail-call site. The removed one-line comment (‘This isn’t really needed but it’s nice to have good book keeping’) on the pre-existing per-argument consume shows the author reasoning explicitly about consume/book-keeping while adding the missing full-stack drain.

The primitive is a consistency-assertion abort (register-allocator book-keeping desync), not a demonstrated memory-corruption write, so the realistic outcome is a controlled crash / denial of service rather than a path to RCE. It is confined to the WebContent (renderer) process where the Wasm JIT runs, inside the WebContent sandbox. Escalation potential is low: the diff shows only that bindings outlive their frame, which trips an internal invariant check; there is no evidence in the patch of attacker-controlled OOB read/write from this state. Standard exploitation background (heap grooming, corrupting adjacent objects to reach ACE) does not apply to what this commit establishes — it is a bookkeeping/DoS fix.