Assigning ulan@ because ishell@ is on vacation.

Re-assinging to the current clussterfuzz sheriff.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

rossberg: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

ClusterFuzz has detected this issue as fixed in range 48853:48854.

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

Fuzzer: inferno_js_fuzzer
Job Type: mac_asan_d8_dbg
Platform Id: mac

Crash Type: CHECK failure
Crash Address: 
Crash State:
  actual_unused_property_fields > map()->unused_property_fields() in objects-debug
  
Sanitizer: address (ASAN)

Fixed: https://clusterfuzz.com/revisions?job=mac_asan_d8_dbg&range=48853:48854

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

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.

ClusterFuzz testcase 4733092253401088 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

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

+awhalley@ (Security TPM) for M63 merge review

There is no CL here. Not sure what needs to be merge here.

awhalley@, could you ptal?

hi bmeurer@ - there's only one V8 issue in the fix range - https://chromium.googlesource.com/v8/v8/+/5e725575d74083c034e52a1d2a522debd208376f%5E%21/#F0 - does that seem reasonable to have fixed this, and if so, what do you think about taking that for M63?

That probably just hides the problem.

bmeurer@ - re-opening

ishell: Uh oh! This issue still open and hasn't been updated in the last 33 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

ishell -- friendly ping from the security sheriff. Can you please share an update on this high severity issue? thanks.

If GC happen while deoptimizer rematerializes objects then heap verifier may complain about half-initialized objects. Probably we need to relax the verification rules during rematerialization.

We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?

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

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

commit e71b802279ccc474820068af7f63218e71a5a48a
Author: Jaroslav Sevcik <jarin@chromium.org>
Date: Mon Dec 04 09:23:03 2017

[deoptimizer] Staged materialization of objects.

The existing object materialization in the deoptimizer has the following problems:

- Objects do not necessarily verify during materialization (because during the
  depth first walk we might have inconsistent objects).

- Stack can overflow (because we just materialize using recursive calls).

- We generalize object fields.


This CL re-implements the materialization algorithm to solve this problem. The
new implementation creates the objects in two steps:

1. We allocate space for all the objects. In general, we allocate ByteArrays
   of the right size. For leaf objects that cannot participate in cycles,
   we build and initialize the materialized objects completely.

   For JS objects, we insert markers into the byte array at the positions
   where unboxed doubles are expected.

2. We initialize all the objects with the proper field values and change the
   map from the ByteArray map to the correct map. This requires some sync
   with the concurrent marker (Heap::NotifyObjectLayoutChange).

   When initializing the JS object fields, we make sure that we respect
   the unboxed double marker.

Bug:  chromium:770106 , v8:3836
Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
Reviewed-on: https://chromium-review.googlesource.com/777559
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49821}
[modify] https://crrev.com/e71b802279ccc474820068af7f63218e71a5a48a/src/deoptimizer.cc
[modify] https://crrev.com/e71b802279ccc474820068af7f63218e71a5a48a/src/deoptimizer.h
[add] https://crrev.com/e71b802279ccc474820068af7f63218e71a5a48a/test/mjsunit/compiler/materialize-dictionary-properties.js
[add] https://crrev.com/e71b802279ccc474820068af7f63218e71a5a48a/test/mjsunit/compiler/materialize-mutable-heap-number.js

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

commit 104a2db3c74b7f13e856ffe999a336cbbe8dd7d8
Author: Jaroslav Sevcik <jarin@chromium.org>
Date: Mon Dec 04 16:02:21 2017

Revert "[deoptimizer] Staged materialization of objects."

This reverts commit e71b802279ccc474820068af7f63218e71a5a48a.

Reason for revert: Need to have a back-mergeable fix.

Original change's description:
> [deoptimizer] Staged materialization of objects.
> 
> The existing object materialization in the deoptimizer has the following problems:
> 
> - Objects do not necessarily verify during materialization (because during the
>   depth first walk we might have inconsistent objects).
> 
> - Stack can overflow (because we just materialize using recursive calls).
> 
> - We generalize object fields.
> 
> 
> This CL re-implements the materialization algorithm to solve this problem. The
> new implementation creates the objects in two steps:
> 
> 1. We allocate space for all the objects. In general, we allocate ByteArrays
>    of the right size. For leaf objects that cannot participate in cycles,
>    we build and initialize the materialized objects completely.
> 
>    For JS objects, we insert markers into the byte array at the positions
>    where unboxed doubles are expected.
> 
> 2. We initialize all the objects with the proper field values and change the
>    map from the ByteArray map to the correct map. This requires some sync
>    with the concurrent marker (Heap::NotifyObjectLayoutChange).
> 
>    When initializing the JS object fields, we make sure that we respect
>    the unboxed double marker.
> 
> Bug:  chromium:770106 , v8:3836
> Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
> Reviewed-on: https://chromium-review.googlesource.com/777559
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49821}

TBR=ulan@chromium.org,mstarzinger@chromium.org,jarin@chromium.org

Change-Id: I0657fb75330700dd7883c600dacb25676ebb47f9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  chromium:770106 , v8:3836
Reviewed-on: https://chromium-review.googlesource.com/806160
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49834}
[modify] https://crrev.com/104a2db3c74b7f13e856ffe999a336cbbe8dd7d8/src/deoptimizer.cc
[modify] https://crrev.com/104a2db3c74b7f13e856ffe999a336cbbe8dd7d8/src/deoptimizer.h
[delete] https://crrev.com/74d339e1dc82da6322bad7fadcabc8e87cfbf54f/test/mjsunit/compiler/materialize-dictionary-properties.js
[delete] https://crrev.com/74d339e1dc82da6322bad7fadcabc8e87cfbf54f/test/mjsunit/compiler/materialize-mutable-heap-number.js

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

commit 1da91b838989cebaca89d7826df23a067bae077a
Author: Jaroslav Sevcik <jarin@chromium.org>
Date: Mon Dec 11 08:45:58 2017

Reland "[deoptimizer] Staged materialization of objects."

This relands commit e71b802279ccc474820068af7f63218e71a5a48a.

This can now back in as the fix for chromium:787301 had enough time to
be tested in Canary.

Original change's description:
> [deoptimizer] Staged materialization of objects.
>
> The existing object materialization in the deoptimizer has the following problems:
>
> - Objects do not necessarily verify during materialization (because during the
>   depth first walk we might have inconsistent objects).
>
> - Stack can overflow (because we just materialize using recursive calls).
>
> - We generalize object fields.
>
>
> This CL re-implements the materialization algorithm to solve this problem. The
> new implementation creates the objects in two steps:
>
> 1. We allocate space for all the objects. In general, we allocate ByteArrays
>    of the right size. For leaf objects that cannot participate in cycles,
>    we build and initialize the materialized objects completely.
>
>    For JS objects, we insert markers into the byte array at the positions
>    where unboxed doubles are expected.
>
> 2. We initialize all the objects with the proper field values and change the
>    map from the ByteArray map to the correct map. This requires some sync
>    with the concurrent marker (Heap::NotifyObjectLayoutChange).
>
>    When initializing the JS object fields, we make sure that we respect
>    the unboxed double marker.
>
> Bug:  chromium:770106 , v8:3836
> Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
> Reviewed-on: https://chromium-review.googlesource.com/777559
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49821}

Bug:  chromium:770106 , v8:3836
Change-Id: Ied6c4e0fbae52713e55ae6dc13794a7521dbb8a5
Reviewed-on: https://chromium-review.googlesource.com/817745
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49982}
[modify] https://crrev.com/1da91b838989cebaca89d7826df23a067bae077a/src/deoptimizer.cc
[modify] https://crrev.com/1da91b838989cebaca89d7826df23a067bae077a/src/deoptimizer.h
[add] https://crrev.com/1da91b838989cebaca89d7826df23a067bae077a/test/mjsunit/compiler/materialize-dictionary-properties.js
[add] https://crrev.com/1da91b838989cebaca89d7826df23a067bae077a/test/mjsunit/compiler/materialize-mutable-heap-number.js

Friendly ping from the security sheriff: Is this fixed by c#11?

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