Integer overflow in DataView constructor allows OOB memory accesses

An integer overflow in DataViewCtor::virtualCallAsConstructor (qv4dataview.cpp:95) allows arbitrary¹ out-of-bounds memory reads and writes:

var buf = new ArrayBuffer(0x200);
var vuln = new DataView(buf, 8, 0xfffffff8);

// As a little demo, here is a hexdumper that reads heap memory from outside of `buf'
function hexdump64(offset) {
    let bytes = [];
    for (let i = 0; i < 8; ++i)
        bytes.push(vuln.getUInt8(offset + i).toString(16).padStart(2, '0'));
    console.log(bytes.join(' '));
}
for (let o = 0x200; o < 0x1000; o += 8)
    hexdump64(o);

Here, the DataView has a very large length, but passes the check in the constructor (line 95) because offset + byteLength overflows (to 0) and is therefore smaller than the bufferLength = buffer->d()>data>size provided by the underlying ArrayBuffer. The example only performs reads, but of course setUint8 also works.

A similar bug in TypedArray.prototype.set was fixed in QTBUG-81102 (and I suspect a fix will look very similar).

Credit for discovering this bug goes to the pasten CTF team, who used it to obtain arbitrary code execution at hxp 36C3 CTF's vvvv challenge².

(For reference: the other solution we know of used QTBUG-81102, and our reference solution used QTBUG-81037, which have both been fixed already.)

¹ Access is limited to the 2³² bytes (4 GiB) past the beginning of the memory of the underlying ArrayBuffer, although that is not a very significant restriction in practice.

² The goal here was to execute code on the host system from qmljs. Admittedly, this setup is a little contrived for real-world security purposes, because it does require running untrusted JavaScript inside of QV4 or qmljs (which one should never do anyways), but it does appear to be a bug either way.