Common Vulnerabilities and Exposures assigned an identifier CVE-2014-1705 to the following vulnerability: Name: CVE-2014-1705 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1705 Assigned: 20140129 Reference: http://googlechromereleases.blogspot.com/2014/03/stable-channel-update-for-chrome-os_14.html Reference: http://googlechromereleases.blogspot.com/2014/03/stable-channel-update_14.html Reference: https://code.google.com/p/chromium/issues/detail?id=351787 Google V8, as used in Google Chrome before 33.0.1750.152 on OS X and Linux and before 33.0.1750.154 on Windows, allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via unknown vectors.
Created v8 tracking bugs for this issue: Affects: fedora-all [bug 1077144] Affects: epel-6 [bug 1077145]
Upstream fix: https://codereview.chromium.org/197793003
And this one also involves a bunch of code not present in v8 3.14. (The only ArrayBuffer and TypedArray classes I can find are in d8.cc, which can't possibly affect chromium or node.)
It seems V8 only got TypedArray support with/after this commit: https://code.google.com/p/v8/source/detail?r=14285 Before that, their support was implemented in d8, rather than in the V8 directly. That implementation seems to have an issue of its own, upstream test (regress-crbug-351787.js) triggers crash on out-of-bounds memcpy() in Shell::ArrayBufferSlice. The following part triggers the issue: var ab1 = new ArrayBuffer(8); ab1.__defineGetter__("byteLength", function() { return 1000000; }); var ab2 = ab1.slice(800000, 900000); Node.js also has its own implementation of TypedArray. Test case for this issue does not trigger any node crash.
(In reply to T.C. Hollingsworth from comment #2) > Upstream fix: https://codereview.chromium.org/197793003 Direct upstream commit link: https://code.google.com/p/v8/source/detail?r=19862