ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=4661480223145984

Ah… so the bug is when we evaluate the fromIndex argument in places like:
- https://cs.chromium.org/chromium/src/v8/src/runtime/runtime-array.cc?rcl=06d36330e481d098c19fe047809d45955837ee46&l=589
- https://cs.chromium.org/chromium/src/v8/src/runtime/runtime-array.cc?rcl=06d36330e481d098c19fe047809d45955837ee46&l=481
- possibly other?

it causes the array to be truncated. But since |len| was read earlier and never re-validated, this will now happily read OOB.

It's crashing in the TF_BUILTIN(ArrayIndexOf,CodeStubAssembler) generated code (the fast path for the builtin). Calling ToInteger there is not safe, as we do the check whether the receiver is a fast mode JSArray first and also load the length first. Both if which can be invalidated after the ToInteger call.

Haha, that bug is actually in the spec, and eg the polyfil on mdn has it as well.

Might be worthwhile to reach out to other browsers and ask then to fix this as well.

It's not a bug in the spec per-se. Stuff like this is all over the specification actually (i.e. it's the same with ValidateTypedArray for example).

Yeah, fair enough :/

Running this gives below stacktrace. Is there a way to get better stacktrace somehow, or not possible inside jit ?

Received signal 11 SEGV_MAPERR 7f6b0c580000

==== C stack trace ===============================

 [0x7f6b13882bf1]
 [0x7f6b137dadb5]
 [0x7f6b0d5c2340]
 [0x7f69a09750a9]
[end of stack trace]

In gdb using our .gdbinit macros, you can use "jco" to print the code object. But otherwise no.

I have a quickfix https://codereview.chromium.org/2756663002, which bails out to the runtime if the fromIndex is not undefined or Smi. But we should really consider doing an audit of the various Array and TypedArray builtins where side-effects can happen after assumptions are made about the receiver.

Our gdbinit is in v8/tools/gdbinit

If you compile with full debug support (is_debug = true v8_optimized_debug = false) then you can use the jst command to print a readable stacktrace.

@aarya: I'm not sure why, but when v8 aborts, the resulting stack trace is never symbolized by default. You might be able to pipe it to addr2line to manually symbolize, but as a followup, it might be worth figuring out if we can make symbolization Just Work for v8.

The problem is why we are using Chrome's stack dump handler at all for v8, and not instead leave to ASAN to catch it and then we should have symbolization by default.

We're not using chrome's handler, but v8's handler. And it should trigger a debug break or something at the end which should give asan a chance to handle this.

However, asan can't handle jitted frames anyways

I cannot get A.p.includes to crash, and the exploit (which is using A.p.includes rather than A.p.index) doesn't seem to work on V8 ToT.

Fix for A.p.indexOf landing now.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/9224d5d1bc61c5054ff79b9c5c700052b85c56d3

commit 9224d5d1bc61c5054ff79b9c5c700052b85c56d3
Author: bmeurer <bmeurer@chromium.org>
Date: Thu Mar 16 06:53:09 2017

[csa] Bailout to the runtime for ToInteger conversion in Array.p.indexOf.

The fast-path for Array.prototype.indexOf first checks whether the
receiver is a fast-mode JSArray (and there are no elements in the
prototype chain in case of holey arrays), then loads the known
JSArray::length, and afterwards calls ToInteger on the fromIndex.

But this ToInteger(fromIndex) call can cause arbitrary side effects if
the fromIndex is a JSReceiver, in particular it can invalidate the
assumptions about the fast-mode of the receiver and the length. In the
worst case this leads to OOB memory access.

Quick-fix is to bailout to the runtime if the fromIndex is neither a Smi
nor undefined, which represents the common cases.

R=jarin@chromium.org
BUG= chromium:702058 

Review-Url: https://codereview.chromium.org/2756663002
Cr-Commit-Position: refs/heads/master@{#43843}

[modify] https://crrev.com/9224d5d1bc61c5054ff79b9c5c700052b85c56d3/src/builtins/builtins-array.cc
[modify] https://crrev.com/9224d5d1bc61c5054ff79b9c5c700052b85c56d3/src/elements.cc
[add] https://crrev.com/9224d5d1bc61c5054ff79b9c5c700052b85c56d3/test/mjsunit/regress/regress-crbug-702058-1.js
[add] https://crrev.com/9224d5d1bc61c5054ff79b9c5c700052b85c56d3/test/mjsunit/regress/regress-crbug-702058-2.js
[add] https://crrev.com/9224d5d1bc61c5054ff79b9c5c700052b85c56d3/test/mjsunit/regress/regress-crbug-702058-3.js

Array.prototype.includes appears to be https://bugs.chromium.org/p/v8/issues/detail?id=5986 which we failed to back-merge to stable :/

The fix for array.prototypes.includes is already on M58 btw. Are the bugs fixed on ToT now or is still something missing?

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Updating OSs, as this was a point of confusion.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+ awhalley@ for M57 merge review

The following additional information was provided by the reporter:

"Very typical bug, redefinition in indexOf and includes. The biggest problem is that these two functions just do some compare and return index or bool, so it is not easy to exploit.

My way is to construct an External String which will do vtable call in String Comparing. If we can control the vtable point to some evil code, know where the fake string is, and put the string pointer follow the redefined String, we will trigger the bug and execute evil code.

To achive this we have to leak some infomation first. I construct the fake String in the ArrayBuffer, and use includes() to bruteforce the buffer's address. On windows platform, a big ArrayBuffer will assigned in a new page, so the lowest 16bits is fixed, so we only needs to bruteforce 16+n bits, n is always less than 10 bits(the high 32bits of the address is always smaller than 0x400 in Windows platform). 

The second problem is that where the evil code is. We found that optimized code does nothing on double values, so we can use double to generate an evil chain(do something than jmp to next double, just like JIT-Spray). But the problem is how to get this address. It is a difficult job indeed. Firstly I use same way to leak the jit address in primitive space. In addition i found that the code space is allocated continuously. So I generate a huge function, which guarantee that this function's optimized code has to be put in a new page. It means the evil code is at the beginning of a page, and we can calculate it for the continuously allocation.

After that, we can call evil code."

Re: #22 I spoke to the reporter and they don't think that the issue with includes is fixed by 67462272919c2ffdba7e0598ce00349a2175ca45 since they were still able to carry out entire chain on ToT as of Tuesday.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=6725323946459136

Reopening according to #32.

I've re-uploaded the testcase to ClusterFuzz: https://clusterfuzz.com/v2/testcase-detail/6288681599238144?noredirect=1

And it said that this is a duplicate of https://clusterfuzz.com/v2/testcase-detail/5486481406951424 found by mbarbella_js_mutation

I'm not sure if they are completely the same, but I'm attaching both CF reports to this bug for auto-verification of further fixes.

Detailed report: https://clusterfuzz.com/testcase?key=6288681599238144

Job Type: windows_asan_d8
Crash Type: UNKNOWN READ
Crash Address: 0x288c0000
Crash State:
  v8::internal::Invoke
  v8::internal::Execution::Call
  v8::Script::Run
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv976yiHzIAPM80Gfd40cSp_daE4DdPbblhfrpFcDVut3dWtgOBc1VZAJsvW7-Loas3HMKb_Lxl5sO7zlciBCyGP7vdoV-xX9TRNTi6ajxobGfCoAanFEhgRfkCXH9R3FbzNCSZHgMWC7PcxwR2lShMxDZNnk2O4qL8kJDyts7ETEwZmmESV98gMS6Ipuyerscaupx7k5A5EvT57Zt32yLcXgDzgAmtuPvfuocMp9kuO7blFwlqHZXBxa_0sPKvSfR11gRMvtmq580ODgjRlrMvoPYTWIM20MQ791VjY5prO_EvHgV9RCQpj2tJ89AVrh6B7kXgFeLryBZh3jM3Kbjq1Al6okZF7HXpoWSEVJ7_L6IhGTyVqJ-w2z6cvLH_B5PsqX4EkzPSqzODrMiwcizD98eFpnbA?testcase_id=6288681599238144


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

Detailed report: https://clusterfuzz.com/testcase?key=5486481406951424

Fuzzer: mbarbella_js_mutation
Job Type: windows_asan_d8
Platform Id: windows

Crash Type: UNKNOWN READ
Crash Address: 0xfffffa24
Crash State:
  v8::internal::Invoke
  v8::internal::Execution::Call
  v8::Script::Run
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv97NPjZdF7fZxsNgrynZmtIDoaMGgelUM04l2GcC6VF9KO2O6ajhihHJjJNyVzG_b2lhLbCXze4MUBLIfaqw_4enrub4YVOaJtn5taZrk1xsE065BdlcxRM72IYg109P5YwYQLUA28m21W3yAeLPCYYnkb_M1tKgcDje9b8aU_xgBoP2HFuQm66xD3xbsCrKDmMMjCmcJWVxldzc30fNaPdsoaybwEdEdIzB7otN4a8ZAITB6JGLNcLoxz2vVFUcGC9CPUZ7DHz3AABcFVEAT2MAk2vg3Zqx_DyRkzbk2Ikj-4X2yETBQTGPbZjjxtNpZpDmSNofh--HnOuKHbO1EXGI-cy7s3-uwV7U0JJfgnIHJ_h6Fh8?testcase_id=5486481406951424


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 702437  has been merged into this issue.

Users experienced this crash on the following builds:

Win Dev 58.0.3029.19 -  0.55 CPM, 113 reports, 95 clients (signature v8::internal::`anonymous namespace'::Invoke)
Mac Canary 59.0.3043.0 -  0.82 CPM, 4 reports, 4 clients (signature v8::internal::`anonymous namespace'::Invoke)
Linux Beta 57.0.2987.98 -  1.15 CPM, 31 reports, 22 clients (signature v8::internal::`anonymous namespace'::Invoke)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Approving for merge to M57 Chrome OS. Please merge by eod today to make this into stable RC.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/328221a16a07a5df8e242ee38af4bc17628f75a8

commit 328221a16a07a5df8e242ee38af4bc17628f75a8
Author: Jakob Kummerow <jakob.kummerow@gmail.com>
Date: Fri Mar 17 20:27:17 2017

Merged: [csa] Bailout to the runtime for ToInteger conversion in Array.p.indexOf.

Revision: 9224d5d1bc61c5054ff79b9c5c700052b85c56d3

BUG= chromium:702058 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Change-Id: I78ffd316bfeaf9db41a8b971d09737b6208204c0
Reviewed-on: https://chromium-review.googlesource.com/456279
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/branch-heads/5.7@{#150}
Cr-Branched-From: 975e9a320b6eaf9f12280c35df98e013beb8f041-refs/heads/5.7.492@{#1}
Cr-Branched-From: 8d76f0e3465a84bbf0bceab114900fbe75844e1f-refs/heads/master@{#42426}
[modify] https://crrev.com/328221a16a07a5df8e242ee38af4bc17628f75a8/src/builtins/builtins-array.cc
[modify] https://crrev.com/328221a16a07a5df8e242ee38af4bc17628f75a8/src/elements.cc
[add] https://crrev.com/328221a16a07a5df8e242ee38af4bc17628f75a8/test/mjsunit/regress/regress-crbug-702058-1.js
[add] https://crrev.com/328221a16a07a5df8e242ee38af4bc17628f75a8/test/mjsunit/regress/regress-crbug-702058-2.js
[add] https://crrev.com/328221a16a07a5df8e242ee38af4bc17628f75a8/test/mjsunit/regress/regress-crbug-702058-3.js

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/41b50c010cae3380e57b56c03d14945d840a6148

commit 41b50c010cae3380e57b56c03d14945d840a6148
Author: Jakob Kummerow <jakob.kummerow@gmail.com>
Date: Fri Mar 17 21:16:41 2017

Merged: [csa] Bailout to the runtime for ToInteger conversion in Array.p.indexOf.

Revision: 9224d5d1bc61c5054ff79b9c5c700052b85c56d3

BUG= chromium:702058 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Change-Id: I8337c2cc89cd95c4ec48433e5addf11cd3115cda
Reviewed-on: https://chromium-review.googlesource.com/456704
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/branch-heads/5.8@{#37}
Cr-Branched-From: eda659cc5e307f20ac1ad542ba12ab32eaf4c7ef-refs/heads/5.8.283@{#1}
Cr-Branched-From: 4310cd02d2160b1457baed81a2f40063eb264a21-refs/heads/master@{#43429}
[modify] https://crrev.com/41b50c010cae3380e57b56c03d14945d840a6148/src/builtins/builtins-array.cc
[modify] https://crrev.com/41b50c010cae3380e57b56c03d14945d840a6148/src/elements.cc
[add] https://crrev.com/41b50c010cae3380e57b56c03d14945d840a6148/test/mjsunit/regress/regress-crbug-702058-1.js
[add] https://crrev.com/41b50c010cae3380e57b56c03d14945d840a6148/test/mjsunit/regress/regress-crbug-702058-2.js
[add] https://crrev.com/41b50c010cae3380e57b56c03d14945d840a6148/test/mjsunit/regress/regress-crbug-702058-3.js

Per comment #44 and #46, this change is already merged to M57 and M58. Hence, removing "Merge-Approved-57" and "Merge-Approved-58" labels.

Re-marking as fixed.  I believe #32 was saying that this bug wasn't fixed by the issue referenced in #22, not that the fix in #21 isn't correct. Could you confirm wfh@?

I am concerned about the speed at which this was merged to m57 stable. Normally there would be a bake period (48hr) on dev or beta before a stable merge. I am also concerned about the fracas posting about a crash spike. Can this be investigated as a matter of urgency?

Note: there's a large spike in renderer crashes in 59.0.3044.0 for 'v8::internal::`anonymous namespace'::Invoke', which comment 41 associated with this bug:
https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20product.version%3D%2759.0.3044.0%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27canary%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27renderer%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27v8%3A%3Ainternal%3A%3A%60anonymous%20namespace%5C%27%3A%3AInvoke%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D

Can someone take a look at these (e.g., crash 790d25e660000000) just to make sure that the spike isn't due to this?

Everyone directly involved in these fixes/merges is in MUC, so they're likely gone for the weekend. I'll take up creis@'s request to look into the crash spike, but on its face #41 doesn't worry me particularly: crashes in Invoke just mean "some crash in generated code", and I'd be shocked if Fracas had figured out how to attribute those automatically to particular CLs.

adamk@: Thanks for looking!  I've filed issue 702793 in case it's due to a different CL.  There's almost 4000 of these (at 93% of all renderer crashes), so it's urgent whatever the cause is.

Sounds like the crash spike isn't due to this fix, given comment 6 on issue 702793.  (Thanks adamk@!)

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/baf1b51a2a512e621863b384a978d47d99273e5d

commit baf1b51a2a512e621863b384a978d47d99273e5d
Author: Adam Klein <adamk@chromium.org>
Date: Fri Mar 17 23:08:21 2017

Revert "Merged: [csa] Bailout to the runtime for ToInteger conversion in Array.p.indexOf."

This reverts commit 328221a16a07a5df8e242ee38af4bc17628f75a8.

Reason for revert: Waiting for time to bake on Canary

Original change's description:
> Merged: [csa] Bailout to the runtime for ToInteger conversion in Array.p.indexOf.
> 
> Revision: 9224d5d1bc61c5054ff79b9c5c700052b85c56d3
> 
> BUG= chromium:702058 
> LOG=N
> NOTRY=true
> NOPRESUBMIT=true
> NOTREECHECKS=true
> 
> Change-Id: I78ffd316bfeaf9db41a8b971d09737b6208204c0
> Reviewed-on: https://chromium-review.googlesource.com/456279
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/branch-heads/5.7@{#150}
> Cr-Branched-From: 975e9a320b6eaf9f12280c35df98e013beb8f041-refs/heads/5.7.492@{#1}
> Cr-Branched-From: 8d76f0e3465a84bbf0bceab114900fbe75844e1f-refs/heads/master@{#42426}

TBR=jkummerow@chromium.org,ishell@chromium.org,ulan@chromium.org,v8-reviews@googlegroups.com,v8-merges@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= chromium:702058 

Change-Id: Icd26235c84987c82f86bcf9ce99f652db5f83a03
Reviewed-on: https://chromium-review.googlesource.com/456926
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/branch-heads/5.7@{#152}
Cr-Branched-From: 975e9a320b6eaf9f12280c35df98e013beb8f041-refs/heads/5.7.492@{#1}
Cr-Branched-From: 8d76f0e3465a84bbf0bceab114900fbe75844e1f-refs/heads/master@{#42426}
[modify] https://crrev.com/baf1b51a2a512e621863b384a978d47d99273e5d/src/builtins/builtins-array.cc
[modify] https://crrev.com/baf1b51a2a512e621863b384a978d47d99273e5d/src/elements.cc
[delete] https://crrev.com/233c7aa3c117e6ccef8b447a5232d5062bf9b784/test/mjsunit/regress/regress-crbug-702058-1.js
[delete] https://crrev.com/233c7aa3c117e6ccef8b447a5232d5062bf9b784/test/mjsunit/regress/regress-crbug-702058-2.js
[delete] https://crrev.com/233c7aa3c117e6ccef8b447a5232d5062bf9b784/test/mjsunit/regress/regress-crbug-702058-3.js

Thanks for confirming creis@!  Even so, we need some more bake time on this before merging to 57.  #56 reverts that merge.  (Thanks again adamk@!)

Re: #48 the reporter said that the same fix in #21 should be applied to the A.p.includes code as well, that's what I understood from what they were saying, anyway.

I think this should be safe to merge to 5.7 as it has beta coverage. We also need to merge the includes patch too though?

wfh@ WTYT?

For reference, the fix was included in V8 Version 5.8.283.19 which went out on the Beta channel on 03/22/17, 03/23/17 for Android and WebView.

I agree this should be merged to M57 given the bake time on Beta and the lack of any stability issues.

Approving merge to M57 branch 2987 based on comment #62 and per char with wfh@. Please merge ASAP so we can take it in for today's M57 Desktop Stable RC cut.

Note: Android M57 Stable RC is already cut so this fix won't be included. amineer@, please correct me if I'm missing anything here.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/11894a324eaf7a8461a8a549b4b121ebffee5def

commit 11894a324eaf7a8461a8a549b4b121ebffee5def
Author: Adam Klein <adamk@chromium.org>
Date: Mon Mar 27 19:09:34 2017

Merged: [csa] Bailout to the runtime for ToInteger conversion in Array.p.indexOf.

Revision: 9224d5d1bc61c5054ff79b9c5c700052b85c56d3

This is a revert of the previous revert (baf1b51a).

TBR=ishell@chromium.org
BUG= chromium:702058 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

Change-Id: Ia351b3ff0350a556bf6b8500a7f3af25c480bf58
Reviewed-on: https://chromium-review.googlesource.com/461204
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/branch-heads/5.7@{#154}
Cr-Branched-From: 975e9a320b6eaf9f12280c35df98e013beb8f041-refs/heads/5.7.492@{#1}
Cr-Branched-From: 8d76f0e3465a84bbf0bceab114900fbe75844e1f-refs/heads/master@{#42426}
[modify] https://crrev.com/11894a324eaf7a8461a8a549b4b121ebffee5def/src/builtins/builtins-array.cc
[modify] https://crrev.com/11894a324eaf7a8461a8a549b4b121ebffee5def/src/elements.cc
[add] https://crrev.com/11894a324eaf7a8461a8a549b4b121ebffee5def/test/mjsunit/regress/regress-crbug-702058-1.js
[add] https://crrev.com/11894a324eaf7a8461a8a549b4b121ebffee5def/test/mjsunit/regress/regress-crbug-702058-2.js
[add] https://crrev.com/11894a324eaf7a8461a8a549b4b121ebffee5def/test/mjsunit/regress/regress-crbug-702058-3.js

ClusterFuzz has detected this issue as fixed in range 458431:458466.

Detailed report: https://clusterfuzz.com/testcase?key=5486481406951424

Fuzzer: mbarbella_js_mutation
Job Type: windows_asan_d8
Platform Id: windows

Crash Type: UNKNOWN READ
Crash Address: 0xfffffa24
Crash State:
  v8::internal::Invoke
  v8::internal::Execution::Call
  v8::Script::Run
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Fixed: https://clusterfuzz.com/revisions?job=windows_asan_d8&range=458431:458466

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv97NPjZdF7fZxsNgrynZmtIDoaMGgelUM04l2GcC6VF9KO2O6ajhihHJjJNyVzG_b2lhLbCXze4MUBLIfaqw_4enrub4YVOaJtn5taZrk1xsE065BdlcxRM72IYg109P5YwYQLUA28m21W3yAeLPCYYnkb_M1tKgcDje9b8aU_xgBoP2HFuQm66xD3xbsCrKDmMMjCmcJWVxldzc30fNaPdsoaybwEdEdIzB7otN4a8ZAITB6JGLNcLoxz2vVFUcGC9CPUZ7DHz3AABcFVEAT2MAk2vg3Zqx_DyRkzbk2Ikj-4X2yETBQTGPbZjjxtNpZpDmSNofh--HnOuKHbO1EXGI-cy7s3-uwV7U0JJfgnIHJ_h6Fh8?testcase_id=5486481406951424


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

Detailed report: https://clusterfuzz.com/testcase?key=6288681599238144

Job Type: windows_asan_d8
Crash Type: UNKNOWN READ
Crash Address: 0x288c0000
Crash State:
  v8::internal::Invoke
  v8::internal::Execution::Call
  v8::Script::Run
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_d8&range=450818:452941

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv976yiHzIAPM80Gfd40cSp_daE4DdPbblhfrpFcDVut3dWtgOBc1VZAJsvW7-Loas3HMKb_Lxl5sO7zlciBCyGP7vdoV-xX9TRNTi6ajxobGfCoAanFEhgRfkCXH9R3FbzNCSZHgMWC7PcxwR2lShMxDZNnk2O4qL8kJDyts7ETEwZmmESV98gMS6Ipuyerscaupx7k5A5EvT57Zt32yLcXgDzgAmtuPvfuocMp9kuO7blFwlqHZXBxa_0sPKvSfR11gRMvtmq580ODgjRlrMvoPYTWIM20MQ791VjY5prO_EvHgV9RCQpj2tJ89AVrh6B7kXgFeLryBZh3jM3Kbjq1Al6okZF7HXpoWSEVJ7_L6IhGTyVqJ-w2z6cvLH_B5PsqX4EkzPSqzODrMiwcizD98eFpnbA?testcase_id=6288681599238144


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

The recommended severity is different from what was assigned to the bug. Please double check the accuracy of the assigned severity.

Also needed on Node.js 7.x (V8 5.5). I can handle the backport.

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

ClusterFuzz testcase 6288681599238144 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

#75: I can't repro. (I tried on Linux, while that testcase uses Windows, but the bug was platform independent, so that shouldn't make a difference.) ClusterFuzz, are you confused?

ClusterFuzz has detected this issue as fixed in range 456626:457730.

Detailed report: https://clusterfuzz.com/testcase?key=6288681599238144

Job Type: windows_asan_d8
Crash Type: UNKNOWN READ
Crash Address: 0x0f440000
Crash State:
  v8::internal::Invoke
  v8::internal::Execution::Call
  v8::Script::Run
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_d8&range=450818:452941
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_d8&range=456626:457730

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6288681599238144


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.

Not merging to Node 7 as it is no longer supported.