The bug is in the OMG (Optimized Machine-code Generator, the top Wasm tier) call emitter OMGIRGenerator::addCall in Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp. addCall emits a direct wasm-to-wasm call and registers a link task that patches the near-call target once the callee is laid out. The invariant at issue is the caller’s calling convention around the stack pointer: after a call returns (or after control comes back into the current frame’s code region), the stack pointer must equal callFrameRegister - frameSize so that all subsequent stack-relative accesses in the frame are correct. The reproducer performs a WebAssembly tail call (return_call, opcode 0x12) from ‘main’ to a callee whose signature has far fewer parameters/results than the caller (the caller type has 26 params, the tail-called helper type has 0), executed in a countdown loop of 100000 iterations to force OMG tier-up (–jitPolicyScale=0, –useConcurrentJIT=0). When a tail call targets a function with a different (smaller) argument area, the shared/near-call and argument-shuffling code can leave the stack pointer adjusted to the callee’s frame layout rather than the caller’s, so on the surrounding OMG-generated code path the SP no longer matches callFrameRegister - frameSize. With a desynchronized SP, subsequent frame accesses and the next stack-limit/overflow reasoning operate on wrong addresses, producing an unexpected crash (and, more broadly, stack-pointer corruption).

The fix adds, inside the link task run after the call is emitted, jit.addPtr(TrustedImm32(-params.code().frameSize()), GPRInfo::callFrameRegister, MacroAssembler::stackPointerRegister), i.e. it explicitly recomputes sp = callFrameRegister - frameSize, restoring the caller-frame SP invariant after the (tail) call sequence. Because params.code().frameSize() is only known late, the restore is deferred into the link task alongside the call-target patch. NOTE: the exact tail-call vs normal-call framing detail is partly inference from the test name (omg-tail-call-to-function-with-less-arguments) and the single-line SP-restore fix; the diff itself only shows the added SP recomputation in addCall’s link task.

The patch establishes a stack-pointer desynchronization after a call/tail-call, which as demonstrated yields an unexpected crash (DoS) of the WebContent (renderer) process, matching the CVE. A wrong SP relative to the frame is a stack-memory-safety issue in principle (subsequent reads/writes land at attacker-influenced offsets), so escalation beyond a crash toward controlled stack corruption cannot be fully excluded, but the diff only shows the SP-restore fix and does not demonstrate a controllable OOB write, so any RCE path is inference rather than established. It is confined to the sandboxed renderer where the Wasm JIT executes; heap-grooming/ACE background is not what this commit proves.