Heap-buffer-overflow in v8::internal::Simulator::DecodeType6CoprocessorIns |
||||||||
Issue descriptionDetailed report: https://cluster-fuzz.appspot.com/testcase?key=5207823032254464 Fuzzer: mbarbella_js_mutation Job Type: linux_asan_d8_ignition_v8_arm_dbg Platform Id: linux Crash Type: Heap-buffer-overflow WRITE 4 Crash Address: 0xdd220d10 Crash State: v8::internal::Simulator::DecodeType6CoprocessorIns v8::internal::Simulator::InstructionDecode v8::internal::Simulator::Execute Recommended Security Severity: High Regressed: V8: r37469:37470 Minimized Testcase (0.38 Kb): Download: https://cluster-fuzz.appspot.com/download/AMIfv96fKkNbT8NXpqoRndbFg5yqayt5zs9JJos6_IosWAMbUR37IiJM_ngsxuR_5FyWiSLhMjKYtG1gh0YTEJEItsMgpD5t5bZl3ousej7qQSrmfb3bg5f_J_D9XlbQki7E5MSlAt1v1dPFy9yyaxN2t7VpqDxUAg?testcase_id=5207823032254464 __v_12 = this; function __f_64(expected, __f_82, __f_11) { __f_82(__v_12, __f_11, new ArrayBuffer(1)).__f_25(); } function __f_6() { } (function() { })(); function __f_60(__v_12, __v_41, heap) { "use asm"; var __v_13 = new __v_12.Float32Array(heap); function __f_82() { var __v_30 = 1.23; __v_13[0] = __v_30; } return {__f_25: __f_82}; } __f_64(1.23, __f_60); ( { })(); Issue manually filed by: rossberg See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
,
Oct 10 2016
,
Oct 10 2016
This is still behind a flag, right? If not, please re-assess security impact.
,
Jan 17 2017
,
May 25 2017
,
Sep 19 2017
Brad any update on this issue? If this option is behind a flag does it warrant a P1 status still. (just going through blink SLO violations as blink triage sheriff)
,
Oct 26 2017
Please reduce priority if this is not P1 priority.
,
Dec 12 2017
Ping (on behalf of triage sheriff)
,
Feb 14 2018
If this is a bug in production code, it's past its 60-day deadline and we need to get someone on it. If it's simulator-only, please note that fact and mark it as a Type=Bug and remove the security labels. Thank you! Also, it would presumably affect all V8 platforms, right?
,
Feb 15 2018
This was only affecting the "old asm.js validator", the "new asm.js validator" correctly reports the instantiation with an ArrayBuffer of size 1 as bogus. This is no longer actionable ...
$ ./out/x64.debug/d8 test/mjsunit/foo.js
test/mjsunit/foo.js:75: Linking failure in asm.js: Unexpected heap size
test/mjsunit/foo.js:77: RangeError: byte length of Float32Array should be a multiple of 4
var __v_13 = new __v_12.Float32Array(heap);
^
RangeError: byte length of Float32Array should be a multiple of 4
at new Float32Array (<anonymous>)
at __f_60 (test/mjsunit/foo.js:77:16)
at __f_64 (test/mjsunit/foo.js:69:2)
at test/mjsunit/foo.js:84:1
,
May 24 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by rossberg@chromium.org
, Oct 10 2016Status: Assigned (was: Untriaged)