Ensure that MurmurHash3_64.update handles ArrayBuffer input correctly, to avoid hash-collisions (issue 12533)

Different fonts incorrectly end up with *identical* hashes, despite having different /ToUnicode data.
The issue, and it's very interesting that we've apparently not seen it before, appears to be caused by the fact that different /ToUnicode entries share the *same* underlying `ArrayBuffer`, which thus becomes problematic at the `const dataUint32 = new Uint32Array(data.buffer, 0, blockCounts);` line. The simplest solution thus seem to be to just *copy* the input, when it's an `ArrayBuffer`, rather than using it as-is. (Note that if we'd stringified the input, when calling `MurmurHash3_64.update`, the issue would also have been fixed. In this case, we're already creating an unique TypedArray.)
This commit is contained in:
Jonas Jenwald 2020-10-26 16:20:55 +01:00
parent b2a4dacd31
commit f2fa053c51
3 changed files with 11 additions and 1 deletions

View File

@ -45,7 +45,7 @@ class MurmurHash3_64 {
}
}
} else if (isArrayBuffer(input)) {
data = input;
data = input.slice();
length = data.byteLength;
} else {
throw new Error(

View File

@ -0,0 +1 @@
https://web.archive.org/web/20201026152003/https://www.mass.gov/doc/covid-19-dashboard-october-25-2020/download

View File

@ -2898,6 +2898,15 @@
"link": false,
"type": "eq"
},
{ "id": "issue12533",
"file": "pdfs/issue12533.pdf",
"md5": "9824904320f884eee20d4e4573008e6f",
"rounds": 1,
"link": true,
"firstPage": 17,
"lastPage": 18,
"type": "eq"
},
{ "id": "issue1466",
"file": "pdfs/issue1466.pdf",
"md5": "8a8877432e5bb10cfd50d60488d947bb",