New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 331444 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Jan 2014
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Security

Sign in to add a comment

[LangFuzz] Crash at v8::internal::StoreBuffer::Compact with invalid write

Reported by, Jan 3 2014

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0

Steps to reproduce the problem:
1. Run the following JS code in d8 as used in the specified Chrome version (SVN r18421, branch 3.23, 64 bit):

function boom() {
  var args = [];
  for (var i = 0; i < 125000; i++)
  return Array.apply(Array, args);
var array = boom();
function fib(n) {
  var f0 = 0, f1 = 1;
  for (; n > 0; n = n -1) {
    f0 + f1;
    f0 = array;

What is the expected behavior?
No crash.

What went wrong?
d8 crashes with a GC corruption:

==15142== Invalid write of size 8
==15142==    at 0x6D3923: v8::internal::StoreBuffer::Compact() (in 3.23/out/x64.release/d8)
==15142==    by 0x5C4A5C: v8::internal::MarkCompactCollector::MigrateObject(unsigned char*, unsigned char*, int, v8::internal::AllocationSpace) (in 3.23/out/x64.release/d8)
==15142==    by 0x5C55F5: v8::internal::MarkCompactCollector::DiscoverAndPromoteBlackObjectsOnPage(v8::internal::NewSpace*, v8::internal::NewSpacePage*) (in 3.23/out/x64.release/d8)
==15142==    by 0x5C5C43: v8::internal::MarkCompactCollector::EvacuateNewSpace() (in 3.23/out/x64.release/d8)
==15142==    by 0x5DD285: v8::internal::MarkCompactCollector::EvacuateNewSpaceAndCandidates() (in 3.23/out/x64.release/d8)
==15142==    by 0x5DF273: v8::internal::MarkCompactCollector::SweepSpaces() (in 3.23/out/x64.release/d8)
==15142==    by 0x5DF361: v8::internal::MarkCompactCollector::CollectGarbage() (in 3.23/out/x64.release/d8)
==15142==    by 0x500DE6: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GCTracer*) (in 3.23/out/x64.release/d8)
==15142==    by 0x501404: v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollector, char const*, char const*) (in 3.23/out/x64.release/d8)
==15142==    by 0x6104E0: v8::internal::JSObject::SetFastElementsCapacityAndLength(v8::internal::Handle<v8::internal::JSObject>, int, int, v8::internal::JSObject::SetFastElementsCapacitySmiMode) (in 3.23/out/x64.release/d8)
==15142==    by 0x63187E: v8::internal::JSObject::SetDictionaryElement(v8::internal::Handle<v8::internal::JSObject>, unsigned int, v8::internal::Handle<v8::internal::Object>, PropertyAttributes, v8::internal::StrictModeFlag, bool, v8::internal::SetPropertyMode) (in 3.23/out/x64.release/d8)
==15142==    by 0x632380: v8::internal::JSObject::SetElementWithoutInterceptor(v8::internal::Handle<v8::internal::JSObject>, unsigned int, v8::internal::Handle<v8::internal::Object>, PropertyAttributes, v8::internal::StrictModeFlag, bool, v8::internal::SetPropertyMode) (in 3.23/out/x64.release/d8)
==15142==  Address 0x21de18914000 is not stack'd, malloc'd or (recently) free'd

I was not able to reproduce this properly in my release build of Chromium, but I suspect this is due to different GC timings and with a little effort, this could be solved. A test for d8 is also likely to be more valuable to find the actual problem.

Did this work before? Yes V8 branch 3.22 seems to work fine.

Chrome version: 33.0.1750.5  Channel: dev
OS Version: Ubuntu Linux 12.04 LTS
Flash Version: Shockwave Flash 11.2 r202

In branch 3.22 I get this weird error:

test.js:3: illegal access
  for (var i = 0; i < 125000; i++)

instead of a crash.
Project Member

Comment 1 by ClusterFuzz, Jan 3 2014

Labels: Cr-Blink-JavaScript

Comment 2 by, Jan 3 2014

Status: Assigned
Assign to current V8 sheriff.

Comment 4 by, Jan 3 2014

The stack trace looks similar to

decoder.oh, can you reproduce this reliably in standalone d8 or does it require running with valgrind?

In the latter case, could you please post command line you use to invoke it?

I tried r18421 with
# out/x64.release/d8 test-1.js
# tools/ out/x64.release/d8 test-1.js
and could not reproduce the crash.

It seems that due to a configuration mistake in the fuzzer, it was using v8-trunk, not v8-3.23. I confirmed that the issue reproduces on v8-trunk, latest revision.

Maybe this still helps you to track down your GC regression :)
Ah, now it also reproduces on 3.23, but you need to use --expose_gc:

$ LangFuzz/3.23/out/x64.release/d8 --expose_gc min.js
Segmentation fault

I don't know exactly why that option matters here because gc() isn't explicitly called. But the branch is affected :) Sorry for the confusion.

Comment 7 by, Jan 3 2014

Thanks, decoder.oh.

With --expose_gc, I can reproduce the crash.
Project Member

Comment 8 by ClusterFuzz, Jan 5 2014

Labels: Missing_Severity-1 Missing_Impact-1
Project Member

Comment 9 by ClusterFuzz, Jan 5 2014

ClusterFuzz is analyzing your testcase. See
Labels: -Missing_Severity-1 Security_Severity-High
Project Member

Comment 11 by ClusterFuzz, Jan 5 2014

Labels: -Pri-2 Pri-1

Comment 12 by, Jan 7 2014

I think I found the bug. In StoreBuffer::ExemptPopularPages:
the check (old_counter == threshold) doesn't make sense to me. I think it should be (old_counter >= threshold). With this fix, the crash doesn't reproduce.

Michael, Hannes, do you agree? If yes, I'll upload the fix.
Labels: reward-topanel
Yes Ulan, LGTM. Upload the fix.

Comment 15 by, Jan 7 2014

Thanks, Hannes. The fix is here:
Status: Fixed
Project Member

Comment 17 by ClusterFuzz, Jan 9 2014

Labels: -Restrict-View-SecurityTeam Merge-Triage Restrict-View-SecurityNotify
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on

- Your friendly ClusterFuzz

Comment 18 by, Jan 16 2014

Labels: -Merge-Triage M-32 Merge-Requested
We got canary coverage. Merged to V8 branch 3.23 (M33):

I will merge to V8 branch 3.22 (M32) after getting merge approval.

Comment 19 by, Jan 16 2014

Labels: Merge-Merged-1750

Comment 20 by, Jan 17 2014

ulan how safe is this? it didn't go to m33 beta yet but i am cutting stable so i need you to let me know. else it will have to wait till round 3 if we have one.

Comment 21 by, Jan 20 2014

kareng@, this should be safe.

Comment 22 by, Jan 21 2014


Comment 23 by, Jan 21 2014

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved Merge-Merged-1700
Merged the fix to V8's 3.22 branch:
Labels: Release-1-M32

Comment 26 by, Jan 23 2014

Labels: CVE-2013-6650
Labels: -reward-topanel reward-unpaid reward-3000
Thanks for the report! This one qualifies for a $3000 reward because it seems like the address that is written to is controllable.
Labels: -reward-unpaid reward-inprocess
Labels: -reward-inprocess
Processing via our e-payment system can take a few weeks, but reward should be on its way to you. Please do NOT publicly disclose details until a fix has been released to all our users. Thanks again for your help!
Project Member

Comment 30 by ClusterFuzz, Apr 17 2014

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Project Member

Comment 31 by ClusterFuzz, May 16 2014

Labels: -Release-1-M32
This bug is a regression and does not impact stable. Removing incorrectly added Release-1-M32 label.

- Your friendly ClusterFuzz
Project Member

Comment 32 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 33 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment