New issue
Advanced search Search tips

Issue 642063 link

Starred by 1 user
Status: Fixed
Owner:
jarin@chromium.org
Closed: Aug 2016
Cc:
mlippautz@chromium.org
ishell@chromium.org
mstarzinger@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Security



Sign in to add a comment

Crash in v8::internal::HeapObject::SizeFromMap

Project Member Reported by ClusterFuzz, Aug 29 2016 
Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4597325974732800

Fuzzer: mbarbella_js_mutation
Job Type: windows_asan_d8
Platform Id: windows

Crash Type: UNKNOWN READ
Crash Address: 0x7847e118
Crash State:
  v8::internal::HeapObject::SizeFromMap
  v8::internal::BodyDescriptorBase::IteratePointers<class v8::internal::MarkCompac
  v8::internal::FlexibleBodyVisitor<class v8::internal::MarkCompactMarkingVisitor,
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=windows_asan_d8&range=414942:414943

Minimized Testcase (0.18 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv97IsOlcUUjpPy4Wu9bu5qfm1hZXmd5ynRAopW93HlO2CS7RMnXFukn3OQGh7VM2w_E7AW_eanYYmcrL6tz_YCsoS2C3Gh511jVfrKLIn026qA7vWN4qqP1f67N0Y6vFMiOxyB6bGBdNkGxWhWgzC9Z5IKviuw?testcase_id=4597325974732800
  var __v_1 = new Array();
  var __v_2 = __v_1;
  gc(); gc();
  for (var __v_0 = -1073741825; __v_0 < 1073741824; __v_0++) {
    __v_2[1] = new Array(1000);
    __v_2 = __v_2[1];
  }


Issue filed automatically.

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

Comment 1 by infe...@chromium.org, Aug 29 2016

Cc: ishell@chromium.org mstarzinger@chromium.org
Labels: Pri-1
Owner: jarin@chromium.org
Status: Assigned (was: Untriaged)

Comment 2 by jarin@chromium.org, Aug 30 2016

Cc: mlippautz@chromium.org
Status: Fixed (was: Assigned)
OOM situation, should be fixed by:

commit bb4974d1864502b99e2fd639b6c584031afd47cc
Author: mlippautz <mlippautz@chromium.org>
Date:   Fri Aug 26 05:27:10 2016 -0700

    [heap] Properly propagate allocated space during new space evacuaton in MC
    
    New space evaucation in MC supports, similar to scavenges, fall back allocation
    in old space.
    
    For new space evacuation we support stick and non-sticky modes for fallback. The
    sticky mode essentially removes the capability to allocate in new space while
    the non-sticky mode only falls back for a single allocation.
    
    We use the non-sticky mode for allocations that are too large for a LAB but
    should still go in new space. When such an allocation fails in new space, we
    allocate in old space in non-sticky mode as we would still like to reuse the
    remainder memory in new space. However, in such a case we fail to properly
    report the space allocated in resulting in a missed recorded slot.
    
    BUG= chromium:641270 
    R=ulan@chromium.org
    
    Review-Url: https://codereview.chromium.org/2280943002
    Cr-Commit-Position: refs/heads/master@{#38940}
Project Member

Comment 3 by sheriffbot@chromium.org, Aug 30 2016

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member

Comment 4 by sheriffbot@chromium.org, Dec 6 2016

Labels: -Restrict-View-SecurityNotify allpublic
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