JavaScriptCore’s OMG (optimizing) wasm tier rematerializes the value stack at loop OSR entry by reading values from an OSR scratch buffer in a fixed index order (connectValuesAtEntrypoint / addLoop in OMGIRGenerator). Exception-handling control frames contribute an ’exception’ value that occupies a scratch-buffer slot, and the ordering must match how the source tier laid out the buffer. When the in-place interpreter tier (useWasmIPInt) is enabled, the exception values for enclosing try/catch frames are positioned differently, but the pre-patch OMG code did not account for that: it handled the exception variable unconditionally (only advancing indexInBuffer for try frames) rather than following the IPInt layout, so at OSR entry into a loop nested inside catch handlers it read values from the wrong scratch-buffer slots. Consuming a stack slot at the wrong offset (e.g. treating a non-exception slot as the exception, or misaligning all subsequent values) corrupts the rematerialized value stack, crashing (or type-confusing) the OMG-compiled code.

The fix, when Options::useWasmIPInt() is set, walks the parser control stack and, for each catch frame, loads the exception from the scratch buffer into the frame’s exception variable (and advances indexInBuffer for try frames), matching the IPInt slot layout; it also guards the old exceptionVariable handling with !useWasmIPInt().

The restored invariant is that OSR-entry stack-slot positioning for exception values matches the active lower tier’s scratch-buffer layout.

An OSR-entry stack-slot mispositioning in the OMG wasm JIT when IPInt is enabled and loops are nested in catch handlers, reachable from crafted wasm in the WebContent process. Misaligned value-stack rematerialization is a corruption/type-confusion-class bug; the observed effect is a crash. Confined to WebContent; rated medium.