TypedArray constructor reads bufferByteLength too early

[psmarshall]

In 22.2.4.5 TypedArray ( buffer [ , byteOffset [ , length ] ] ):

In step 9, we store the value of the byte length of the buffer.
9. Let bufferByteLength be buffer.[[ArrayBufferByteLength]].

In step 11.a, we can end up in user-code via ToIndex.
11.a. Let newLength be ? ToIndex(length).

In step 11.c, we use the value of bufferByteLength from step 9 -- which could be totally incorrect now, as 11.a could have neutered the buffer.
11.c. If offset + newByteLength > bufferByteLength, throw a RangeError exception.

If an implementation followed this, it could result in (quite bad) security issues.

[littledan]

I see how this behavior is not what you'd expect--we should probably be doing all conversions before the detached check so that this check can catch as many cases as possible. But I don't see the security issue. A later indexed property access would simply find the underlying ArrayBuffer detached and throw (modulo #678), wouldn't it?

[littledan]

I see how this behavior is not what you'd expect--we should probably be doing all conversions before the detached check so that this check can catch as many cases as possible. But I don't see the security issue. A later indexed property access would simply find the underlying ArrayBuffer detached and throw (modulo #678), wouldn't it?

[psmarshall]

Yes that's true, as long as the property accesses check for detached ArrayBuffer, this won't cause a security problem

[psmarshall]

Yes that's true, as long as the property accesses check for detached ArrayBuffer, this won't cause a security problem