RevalidateAtomicAccess (25.4.3.4) bounds-checks only the first byte of the element being accessed. When a length-tracking TypedArray’s backing resizable ArrayBuffer is shrunk during argument coercion so the target element now starts in bounds but ends past the new, shorter buffer end, the revalidation passes and control reaches a buffer accessor whose "sufficient bytes" assertion is false. Repro:
const ab = new ArrayBuffer(100, { maxByteLength: 100 });
const ta = new Int32Array(ab); // length-tracking; element 24 spans bytes 96..99
Atomics.and(ta, 24, { valueOf() { ab.resize(97); return 1; } });
I came across this from a Ladybird bug report at LadybirdBrowser/ladybird#10759 and implemented a fix in LadybirdBrowser/ladybird#10854.
And the OOB access doesn’t occur in V8, JSC, or SpiderMonkey. So the spec text as currently written doesn’t align with what any existing implementations are actually doing.
RevalidateAtomicAccess(25.4.3.4) bounds-checks only the first byte of the element being accessed. When a length-tracking TypedArray’s backing resizableArrayBufferis shrunk during argument coercion so the target element now starts in bounds but ends past the new, shorter buffer end, the revalidation passes and control reaches a buffer accessor whose "sufficient bytes" assertion is false. Repro:I came across this from a Ladybird bug report at LadybirdBrowser/ladybird#10759 and implemented a fix in LadybirdBrowser/ladybird#10854.
And the OOB access doesn’t occur in V8, JSC, or SpiderMonkey. So the spec text as currently written doesn’t align with what any existing implementations are actually doing.