The commit adds only a WebAssembly regression test (JSTests/wasm/regress/309628.js); the actual fix to the JSC WebAssembly engine is NOT contained in this diff, so the mechanism below is an inference grounded in what the test exercises. The test hand-assembles a minimal Wasm module whose single exported function ‘f’ declares a very large number of i64 locals (the local-declaration entry ‘0x01, …leb(numLocals), 0x7e’ where 0x7e is i64), followed by a trivial body ’local.get 0; drop; end’. A driver sweeps numLocals from 35000 down to 8000 in steps of 2000, instantiating and calling the function until one succeeds without throwing. Crucially the whole thing runs inside a spawned agent/worker ($.agent.start) which typically has a smaller, differently-sized native stack than the main thread. The pattern is the classic ‘many locals’ stress case: each declared local must be reserved and zero-initialized in the function’s stack frame, so a function with tens of thousands of i64 locals demands a very large frame. The violated invariant is that the engine must reserve stack space for all locals and verify it fits within the available native/JS stack (a stack-limit check) before entering the function body; if the required frame size exceeds the thread stack and the check is missing, mis-ordered, or computed with a value that can overflow/wrap, execution runs off the end of the guard region and the process crashes instead of throwing a catchable Wasm/RangeError. The sweep from high to low local counts and the try/catch that breaks on success show the author probing for the exact frame size that lands in the unhandled window between ‘still throws cleanly’ and ‘crashes’, which is the signature of a boundary/stack-check logic error. Running in a worker with a tighter stack makes the vulnerable window reachable at a lower local count. The upstream fix (not shown) most plausibly tightens the stack/frame-size check so that an over-large locals frame produces a clean out-of-memory/stack-exhaustion exception on every thread rather than an uncontrolled overrun. This is consistent with the bug class (LogicError) and stated impact (unexpected process crash).

The demonstrated primitive is an uncontrolled process crash (denial of service) in the WebContent process, driven by native stack exhaustion from an over-large Wasm locals frame; this matches the CVE’s ‘unexpected process crash’ impact and medium severity. As shown, the attacker controls only the frame size, not written contents, so this is a reliability/DoS bug rather than a memory-write primitive; escalation to code execution would require an additional, separate primitive not established by this commit. It is confined to the sandboxed WebContent (JavaScript/Wasm) process. Because the crash depends on hitting a narrow size window that varies with thread stack size, exploitation as a stable, weaponizable memory corruption is not supported by anything in this diff (inference, since the engine fix is not shown).