op_instanceof is a bytecode operation that can call back into JavaScript at two points: fetching the Symbol.hasInstance method on the constructor, and (when the default hasInstance is used) fetching the constructor’s ‘prototype’ property. In LLInt these callouts are modeled as checkpoints (OpInstanceof::getHasInstance, getPrototype, instanceof), and when a DFG/FTL-compiled frame that inlined one of these getters OSR-exits back into the baseline/LLInt tier, execution must resume at a well-defined return location tied to the specific opcode and checkpoint.

The bug is that op_instanceof was never registered in the machinery that maps an inlined-call OSR exit back to its LLInt return PC. LLIntOpcode.h did not declare op_instanceof as an opcode with a return location, BytecodeList.rb did not declare op_instanceof_return_location, LowLevelInterpreter64.asm had no .getHasInstanceInlinedGetterOSRReturnPoint label emitting getterSetterOSRExitReturnPoint for op_instanceof, and callerReturnPC() in DFGOSRExitCompilerCommon.cpp had no case for op_instanceof, so it hit RELEASE_ASSERT_NOT_REACHED(). The invariant violated is that every bytecode capable of OSR-exiting from an inlined getter must have a corresponding LLInt return location so the interpreter can reconstruct where to continue. Because that mapping was absent, when a Symbol.hasInstance (or prototype) getter was inlined into DFG code and then forced to OSR-exit while executing that getter, the exit compiler could not find a valid return PC. The slow-path handler llint_slow_path_checkpoint_osr_exit_from_inlined_call in LLIntSlowPaths.cpp also mishandled the checkpoint states: it eagerly decoded dst/value/hasInstanceOrPrototype up front and tried to re-run the hasInstance dispatch and default-hasInstance logic inside the checkpoint resume, when in fact getHasInstance and instanceof checkpoints should never be reached via an inlined-call OSR exit (the former is not handled by a checkpoint here, the latter has no inlined calls at the last checkpoint).

The fix adds the missing op_instanceof return-location plumbing across all four layers and rewrites the slow path so only the getPrototype checkpoint does work (reading m_dst, the value operand, and the decoded prototype result, then computing defaultHasInstance), while getHasInstance and instanceof both RELEASE_ASSERT_NOT_REACHED. This restores the invariant that an inlined-getter OSR exit for op_instanceof resumes at a real return point and that only the reachable checkpoint state runs.

The patch establishes a reachable RELEASE_ASSERT_NOT_REACHED()/invalid-resume condition triggered deterministically from script via instanceof with a JS getter on Symbol.hasInstance or prototype, so the demonstrated primitive is a controlled, reliable crash of the WebContent (renderer) process rather than a memory-corruption primitive. Nothing in the diff shows a controllable OOB write or UAF; resuming at a wrong return PC could in principle be dangerous, but the patch and tests only evidence a crash/abort, so escalation to code execution is not supported by what the commit shows. Impact is confined to the sandboxed WebContent process; it is a denial-of-service consistent with the advisory’s ‘unexpected process crash.’