This fixes an integer overflow reachable through String.prototype.normalize. In StringPrototype.cpp’s normalize(), JSC calls ICU’s unorm2_normalize in a preflight/allocate/normalize pattern: it first calls with a zero-length output buffer to learn the required length (normalizedStringLength), then allocates and normalizes for real. ICU computes internal buffer lengths with 32-bit arithmetic, and for a sufficiently large input string those length calculations can overflow, so ICU either mis-sizes buffers or reports a memory-allocation error that the caller ignored (the code only ASSERTed needsToGrowToProduceBuffer(status)).

The fix adds two guards: a pre-check that rejects inputs of length >= 2^30 with an OutOfMemoryError before calling ICU at all (the comment cites rdar://160634825 and the ICU overflow), and a check of the ICU status via the new isICUMemoryAllocationError(status) helper (U_MEMORY_ALLOCATION_ERROR) after the preflight call, again throwing OutOfMemoryError instead of proceeding.

The restored invariant is that JSC never continues normalization when the input is large enough to overflow ICU’s length math or when ICU signals an allocation failure; it converts those conditions into a clean JS exception. The vulnerable overflow itself is inside ICU (not shown), so the precise corrupted computation is inferred, but the patch establishes the trigger (huge strings) and the missing status handling.

A controlled process crash / denial of service in the WebContent process from a single normalize() call on a very large string; the overflow lives inside ICU’s length computation. This diff hardens the boundary rather than showing a corrupt write, so the realistic outcome established here is a crash/OOM abort rather than a demonstrated write primitive.