slice & other TypedArray.prototype funcs: shouldn't we reload the length?

[marjakh]

The problem occurs when

• We're using a length tracking TypedArray and calling TypedArray.prototype.slice
• ToIntegerOrInfinity, TypedArraySpeciesCreate etc. calls user code which shrinks the underlying buffer

Example:
let ab = new ArrayBuffer(4, {maxByteLength: 8});
let ta = new Uint8Array(ab); // Length-tracking, offset 0
let evil = { valueOf: () => { rab.resize(2); return 0;}};
ta.slice(evil);

Now:
Step 3: len = 4
Step 4: calling ToIntegerOrInfinity resizes, relativeStart = 0
Step 6: k = 4
Step 8: relativeEnd = 4
Step 11: final = 4
Step 12: count = 4
Step 14 a, b, c do the detachedness & OOB checks. Now the TA is not OOB since it's length tracking.
Step 14.i.ix.1 ends up reading out of bounds memory.

I'm not sure what the cleanest solution is. Do we need to reload the length and do all the computations again? Do we want to reload the length and if it has changed, throw?

This problem probably happens for many TypedArray.prototype functions.

[marjakh]

More info:

In theory, one possibility would be to rearrange the steps to first do the parameter conversions, and only after than read the length. That might help in some cases, but for slice() it's tricky. We'd need to first decide which is the length of the resulting array, then do TypedArraySpeciesCreate which might also end up resizing. So we still need to do something afterwards.

Other funcs:

TypedArray.prototype.at. There we don't have a problem with OOB reads / writes, but I'm not sure what the expected result is. Without any changes, this would return undefined:
let ab = new ArrayBuffer(4, {maxByteLength: 8});
let ta = new Uint8Array(ab); // Length-tracking, offset 0
let evil = { valueOf: () => { rab.resize(2); return -1;}};
ta.at(evil); // undefined?
Maybe that's good enough? Although, a bit unintuitive?

TypedArray.prototype.fill doesn't seem to have this problem, since it'll delegate to IntegerIndexedElementSet which will only fill in valid indices.

TypedArray.prototype.copyWithin seems to have this problem.

(I'd guess funcs that do GetValueFromBuffer / SetValueInBuffer have this problem, and funcs that do [[Get]] and [[Set]] don't.)

[syg]

Ooh, good catch!

I'll fix slice, fill, and copyWithin to use the IntegerIndexedObjectLength and to fix the resize issue. Resize-in-the-middle should be handled the same as when an Array method sneakily changes the array's length in the middle: the length is cached by the algorithm, and it'll end up reading undefineds. In the TypedArray case, when assigned into some target TA, those undefined become 0s if the TA is integral, and NaN if it's floating point.

TypedArray.prototype.at. There we don't have a problem with OOB reads / writes, but I'm not sure what the expected result is. Without any changes, this would return undefined:

Yeah, I think at() is unproblematic.