The DFG constant-folding phase (DFGConstantFoldingPhase.cpp) walks the IR and tries to strength-reduce/eliminate operations on JSArrayBufferViews whose identity is known at compile time. In the branch shown, once the phase has proven it is dealing with a concrete typed-array view it calls m_interpreter.execute(indexInBlock) and sets eliminated = true, folding the operation and, as part of that, baking view-derived state (notably the backing store / vector pointer of the typed array) into the compiled code as a constant. The invariant this relies on is that a typed array’s backing buffer, once observed, does not move for the lifetime of the folded code. That invariant holds for ordinary ArrayBuffers, but it is FALSE for views over resizable ArrayBuffers and growable SharedArrayBuffers: resize() and WebAssembly.Memory.grow() may reallocate the backing store, leaving any previously-folded vector pointer dangling.

The patch adds an early break: if (view->isResizableOrGrowableShared()) { break; } so the phase refuses to fold operations on such views, restoring the invariant by simply not embedding a pointer that can go stale. The added JSTests case demonstrates the path: it grooms the WebAssembly memory pool, creates a WebAssembly.Memory with a resizable buffer, builds a Float64Array over it, warms up trigger() writing view[0] until the DFG compiles it (folding the store against the current backing store), then calls memory.grow(1) to reallocate and finally trigger(1.1) writes through the now-stale folded pointer. The exact node type being folded (a GetByVal/PutByVal or a GetTypedArrayLength/StorePointer style operation) is not literally printed in the diff, so the precise folded value is an inference; what the diff establishes is that folding operations on resizable/growable-shared views was unsound and is now suppressed.

The patch itself is classified LogicError / medium with the stated effect of an unexpected process crash, and the observed primitive is a stale pointer dereference to a freed or relocated buffer (a UAF/OOB read-or-write) from JIT-compiled code running in the WebContent (renderer) process. Because the operand values written through the stale pointer are attacker-controlled and the timing of reallocation is controllable via grooming, a determined attacker could plausibly escalate an OOB write from a controlled crash toward memory disclosure/corruption, but the diff and test only establish a reliable crash, so anything beyond that is inference. It is confined to the WebContent sandbox; no sandbox escape is implied by this commit.