This commit fixes architecture-specific scratch-register handling in the WebAssembly JITs. The central change is in WasmOMGIRGenerator.cpp’s prepareForTailCallImpl(), the code emitted to set up a WebAssembly tail call: it must shuffle the callee’s arguments into place over the current frame and then jump, which requires a scratch register (auto tmp = jit.scratchRegister()). The original code handled the scratch register with logic that is only correct for x86_64: on x64 the MacroAssembler scratch register is a general-purpose register that can alias one of the incoming argument registers, so it may need to be spilled to a stack slot (tmpNeedsSaving / tmpSpillOffsetRelativeToOriginalSP) before being clobbered and reloaded afterward, and after reloading it the code wraps the tail of the sequence in DisallowMacroScratchRegisterUsage because further scratch use could clobber an input. Applying this x64-shaped logic on other architectures (e.g. ARM64, where the assembler scratch is a dedicated data-temp that never aliases wasm argument or callee-save registers) was both unnecessary and unsound: the non-x64 path lacked the frame-restore step needed before the current frame is clobbered.

The patch conditionalizes the spilling logic behind #if CPU(X86_64); on the #else path it instead sets tmpNeedsSaving to a constexpr false, calls jit.emitRestore(calleeSaves) to ‘set up a valid frame so that we can clobber this one,’ and (under ASSERT_ENABLED) adds assertions that the scratch tmp never equals any argument GPR/FPR and is never a callee-save register. The DisallowMacroScratchRegisterUsage guard at the end is likewise restricted to x86_64. The saveSrc lambda’s capture list is changed from an explicit list to [=] so it compiles under both the runtime-bool (x64) and constexpr (non-x64) forms of tmpNeedsSaving/tmpSpillOffsetRelativeToOriginalSP. The second file, WasmBBQJIT.cpp, contains a related x86_64 scratch fix in a constant-operand float shaping branch (the diff’s nearest label is addI32Extend8S but the body does absFloat then a conditional sign flip): on x86_64 the sign negation is now done by moving the float to wasmScratchGPR, xor32 with the 0x80000000 sign bit, and moving back, instead of MacroAssembler negateFloat. The precise way the pre-fix non-x64 tail-call code corrupted state (which register got clobbered, and whether it led to memory corruption versus a controlled trap) is not spelled out in the diff, so that mechanism is an inference; what the diff establishes is that the scratch/frame handling was arch-incorrect off x86_64 and is now split per-CPU with a proper frame restore and debug asserts. The fuzzer-generated JSTests case (a large tail-call-heavy Wasm module invoked via fn5() under a watchdog) is the regression reproducer.

Classified LogicError / medium, the demonstrated effect is an unexpected crash of the WebContent (renderer) process, reachable from unprivileged web content that merely instantiates and calls a crafted Wasm module with tail calls, and it is architecture-dependent (the non-x86_64 path is the one being corrected). A JIT that clobbers the current frame or a live input register during a tail-call shuffle is in principle a strong corruption primitive (attacker-influenced values landing in wrong registers/stack slots), so escalation from crash toward controlled memory corruption is conceivable but is inference; the commit and reproducer only establish a crash. Impact is contained to the WebContent sandbox with no indicated sandbox escape.