During YARR (JavaScriptCore’s regexp engine) pattern compilation, setupAlternativeOffsets/setupDisjunctionOffsets compute the size of the backtracking call frame a regexp needs, accumulating per-construct stack space (e.g. YarrStackSpaceForBackTrackInfoParentheticalAssertion and similar) as a plain unsigned. For a sufficiently large or deeply nested pattern, this running total can exceed 2^32 and wrap around, so the computed newCallFrameSize is far smaller than the space the compiled matcher will actually use. The compiler then sizes the backtracking frame from the wrapped-small value while the matcher indexes it as if it were the true (large) size, an out-of-bounds access of the backtracking stack frame — memory corruption / crash.

The fix changes the call-frame-size accumulators to CheckedUint32 (currentCallFrameSize, initialCallFrameSize, perAlternativeInitial, currentAlternativeCallFrameSize, ignoredCallFrameSize) and, at every accumulation point, returns the new ErrorCode::FrameTooLarge when hasOverflowed() is true, so an over-large pattern is rejected at compile time instead of producing an undersized frame; a TooManyCaptures error code is likewise added. Complementary hardening in AssemblerBuffer.h switches capacity growth to Checked<unsigned> and compares indices as 64-bit to avoid analogous overflow in the code buffer.

The restored invariant is that the regexp backtracking frame size is computed with overflow checking and any pattern whose frame would overflow 32 bits is rejected rather than compiled with a truncated size.

An integer-overflow in regexp backtracking-frame sizing that yields an undersized frame indexed at full offsets — an out-of-bounds read/write on the backtracking stack in the WebContent process. It is reachable directly from a crafted RegExp in web content; the demonstrated effect is a crash, but a controlled frame-size mismatch is a plausible corruption primitive. Rejecting over-large patterns removes it. Rated medium.