CHECK failure: byte_length() <= JSArrayBuffer::kMaxByteLength in objects-debug.cc |
||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5289653387919360 Fuzzer: ochang_js_fuzzer Job Type: linux_asan_d8_v8_arm_dbg Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: byte_length() <= JSArrayBuffer::kMaxByteLength in objects-debug.cc v8::internal::JSArrayBufferView::JSArrayBufferViewVerify v8::internal::JSTypedArray::JSTypedArrayVerify Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_v8_arm_dbg&range=56007:56008 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5289653387919360 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Sep 19
The initialization of JSTypedArray instances with Undefined confuses the heap verifier. The object itself didn't leak to JavaScript at this point, so there's no way to exploit this from user code (removing Security restriction).
,
Sep 19
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/984048e8c7981a38b73a8bbaeb5e6fd7f34c1d95 commit 984048e8c7981a38b73a8bbaeb5e6fd7f34c1d95 Author: Benedikt Meurer <bmeurer@chromium.org> Date: Wed Sep 19 09:28:11 2018 [es2015] Clear JSTypedArray raw fields in the constructor. The JSTypedArray instance is created early on in the TypedArray constructors, using EmitFastNewObject, which puts Undefined into all slots. But the code might still produce an exception afterwards leaving the JSTypedArray in a weird state. It's not a security issue since the object doesn't escape, but it confuses the heap verifier. Bug: chromium:885404 , v8:4153, v8:7881, v8:8171 Change-Id: I5fb8131fcae69edf4a92602ed477dca305c3d6c7 Reviewed-on: https://chromium-review.googlesource.com/1233257 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56019} [modify] https://crrev.com/984048e8c7981a38b73a8bbaeb5e6fd7f34c1d95/src/builtins/builtins-typed-array-gen.cc [add] https://crrev.com/984048e8c7981a38b73a8bbaeb5e6fd7f34c1d95/test/mjsunit/regress/regress-crbug-885404.js
,
Sep 19
,
Sep 19
,
Sep 20
ClusterFuzz has detected this issue as fixed in range 56018:56019. Detailed report: https://clusterfuzz.com/testcase?key=5289653387919360 Fuzzer: ochang_js_fuzzer Job Type: linux_asan_d8_v8_arm_dbg Platform Id: linux Crash Type: CHECK failure Crash Address: Crash State: byte_length() <= JSArrayBuffer::kMaxByteLength in objects-debug.cc v8::internal::JSArrayBufferView::JSArrayBufferViewVerify v8::internal::JSTypedArray::JSTypedArrayVerify Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_v8_arm_dbg&range=56007:56008 Fixed: https://clusterfuzz.com/revisions?job=linux_asan_d8_v8_arm_dbg&range=56018:56019 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5289653387919360 See https://github.com/google/clusterfuzz-tools for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
Sep 20
ClusterFuzz testcase 5289653387919360 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
||||
►
Sign in to add a comment |
||||
Comment 1 by ClusterFuzz
, Sep 19Owner: bmeu...@chromium.org
Status: Assigned (was: Untriaged)