The immutable TypedArray prototype methods toReversed, toSorted and with (genericTypedArrayViewProtoFunc*) computed a length and then, in a separate step, obtained the source data span to copy into the freshly-allocated result. In toReversed/toSorted the code read size_t length = thisObject->length();, allocated the result of that length, then re-fetched from = thisObject->typedSpan() and copied length elements (with only an ASSERT that from.size()==length). When the typed array is backed by a growable SharedArrayBuffer, another agent can grow the SAB (SABs can grow but never shrink) concurrently between the length read and the copy, so the re-fetched span no longer matches the captured length, and the backing storage may have been reallocated. Copying length elements from a span whose size/pointer changed is an out-of-bounds read (and the ASSERT is not present in release builds).

The fix snapshots the span once — auto originalSpan = thisObject->typedSpan(); size_t length = originalSpan.size(); — and copies from that exact snapshot, so the length and the source pointer are mutually consistent; with similarly snapshots maybeUpdatedSpan and compares its size to the earlier length.

The restored invariant is that the element count and the source buffer used for the copy come from a single atomic view of the array, immune to a concurrent grow.

A concurrency OOB read where a stale length is used to copy from a span whose growable-SAB backing changed underneath, in the WebContent process. The attacker controls the race via a worker growing the SAB, giving a repeatable out-of-bounds read that can disclose adjacent heap memory and potentially corrupt the result buffer; turning it into a strong primitive needs race-timing and grooming. Confined to WebContent. Rated medium.