[7] [JSC] Delay PC advancement until after operationCallMayThrow in IPInt

Severity: Medium | Component: JSC IPInt (In-Place Interpreter) | 714bf5b

Rated Medium because the observable effect is wrong-catch selection in Wasm exception dispatch (a deterministic logic error reachable from web content), and escalation to Wasm-level type confusion depends on whether IPInt's catch-entry path rebuilds operand-stack height — an unverified architectural question.

Source/JavaScriptCore/llint/InPlaceInterpreter64.asm

Patch Details

Three IPInt opcode handlers — _call_indirect, _return_call_indirect, _return_call_ref — have their advancePCByReg and advanceMC instructions moved from before the operationCallMayThrow invocation to after it. No guards or new types are introduced; the order change is the entire fix.

Off-by-one in the PC value snapshotted as the call-site index for exception dispatch — PC advanced before the may-throw call records its location.

Background

IPInt is JSC's lowest-tier WebAssembly interpreter, written in offlineasm (InPlaceInterpreter64.asm). Opcode handlers manipulate two pointers — PC (Wasm bytecode) and MC (metadata cursor) — and call C++ helpers via operationCallMayThrow for operations that may unwind. operationCallMayThrow records the current call site index — derived from PC at the moment of the call — into the per-frame state used by Wasm's exception-handler lookup. Wasm exception handling lets a function attach catch blocks to PC ranges; on throw, the runtime selects the innermost matching catch.

Analysis

Pre-fix the three indirect-call handlers advanced PC past the call instruction before invoking operationCallMayThrow, so the saved call site index pointed at the instruction after the call. When the indirect call subsequently threw — via signature mismatch, null table entry, or a callee throw — the unwinder used this off-by-one index to scan the function's exception-handler table.

Audit directions