ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=4666714122616832.

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5311973634605056.

Can you explain this attack in a bit more detail? Loading the attack in Chrome 68 seems to simply hang the tab without any sort of crash. 

Please supply information about what version of Chrome (see chrome://version) crashed with this test case. Do you have a crash .DMP file or other details about the crash?

The chrome version is 66.0.3359.139 for windows.
The attachment is a dump file.

Deleted: index-debug.dump 2.3 KB

index-debug.dump 2.3 KB Download

Deleted: index-release.dump 4.0 KB

index-release.dump 4.0 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

I was hoping for an actual .DMP file that could be loaded into WinDBG, but there's at least *some* info in these text traces:

#
# Fatal error in ../../src/heap/heap-inl.h, line 331
# Debug check failed: !result || gc_state_ != NOT_IN_GC || InToSpace(object).
#
#
#
#FailureMessage Object: 0x7ffeee241ca0
==== C stack trace ===============================

    0   libv8_libbase.dylib                 0x0000000102fbb9b3 v8::base::debug::StackTrace::StackTrace() + 19
    1   libv8_libplatform.dylib             0x0000000102fe5319 v8::platform::(anonymous namespace)::PrintStackTrace() + 41
    2   libv8_libbase.dylib                 0x0000000102fb3ca5 V8_Fatal(char const*, int, char const*, ...) + 325
    3   libv8_libbase.dylib                 0x0000000102fb37d5 v8::base::(anonymous namespace)::DefaultDcheckHandler(char const*, int, char const*) + 21
    4   libv8.dylib                         0x0000000101f4ebde v8::internal::(anonymous namespace)::FullEvacuationVerifier::VerifyPointers(v8::internal::Object**, v8::internal::Object**) + 654
    5   libv8.dylib                         0x0000000101f4ef92 v8::internal::(anonymous namespace)::EvacuationVerifier::VerifyEvacuation(v8::internal::NewSpace*) + 258
    6   libv8.dylib                         0x0000000101f3f834 v8::internal::MarkCompactCollector::EnsureSweepingCompleted() + 212
    7   libv8.dylib                         0x0000000101effb59 v8::internal::Heap::Verify() + 137
    8   libv8.dylib                         0x0000000101f01a8c v8::internal::Heap::GarbageCollectionEpilogue() + 332
    9   libv8.dylib                         0x0000000101f05034 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) + 1380
    10  libv8.dylib                         0x0000000101f03758 v8::internal::Heap::HandleGCRequest() + 200
    11  libv8.dylib                         0x0000000101e81c5a v8::internal::StackGuard::HandleInterrupts() + 186
    12  libv8.dylib                         0x00000001022a399f v8::internal::__RT_impl_Runtime_StackGuard(v8::internal::Arguments, v8::internal::Isolate*) + 143
    13  ???                                 0x00001306bed84344 0x0 + 20919692575556
    14  ???                                 0x00001306bee8d519 0x0 + 20919693661465
Received signal 4 <unknown> 000102fb9862
zsh: illegal hardware instruction  ~/Project/chrome/v8/v8/out.gn/x64-debug.6.8.1/d8 --verify-heap index-debug.js


(2960.2458): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
chrome_child!v8::internal::CopyWords+0x368 [inlined in chrome_child!v8::internal::Scavenger::ScavengeObject+0x5cf]:
00007ffa`364aadbf 48896cc130      mov     qword ptr [rcx+rax*8+30h],rbp ds:00000d96`2e780000=????????????????
0:016> k 20
 # Child-SP          RetAddr           Call Site
00 (Inline Function) --------`-------- chrome_child!v8::internal::CopyWords+0x368 [C:\b\c\b\win64_clang\src\v8\src\utils.h @ 1136] 
01 (Inline Function) --------`-------- chrome_child!v8::internal::Heap::CopyBlock+0x37a [C:\b\c\b\win64_clang\src\v8\src\heap\heap-inl.h @ 480] 
02 (Inline Function) --------`-------- chrome_child!v8::internal::Scavenger::MigrateObject+0x392 [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger-inl.h @ 49] 
03 (Inline Function) --------`-------- chrome_child!v8::internal::Scavenger::PromoteObject+0x44f [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger-inl.h @ 108] 
04 (Inline Function) --------`-------- chrome_child!v8::internal::Scavenger::EvacuateObjectDefault+0x542 [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger-inl.h @ 137] 
05 (Inline Function) --------`-------- chrome_child!v8::internal::Scavenger::EvacuateObject+0x590 [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger-inl.h @ 217] 
06 0000008d`569ff530 00007ffa`364ae4f0 chrome_child!v8::internal::Scavenger::ScavengeObject+0x5cf [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger-inl.h @ 240] 
07 (Inline Function) --------`-------- chrome_child!v8::internal::Scavenger::CheckAndScavengeObject+0x3b [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger-inl.h @ 251] 
08 (Inline Function) --------`-------- chrome_child!v8::internal::Scavenger::ScavengePage::<unnamed-tag>::operator()+0x3b [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger.cc @ 104] 
09 (Inline Function) --------`-------- chrome_child!v8::internal::SlotSet::Iterate+0xc0 [C:\b\c\b\win64_clang\src\v8\src\heap\slot-set.h @ 206] 
0a (Inline Function) --------`-------- chrome_child!v8::internal::RememberedSet<v8::internal::OLD_TO_NEW>::Iterate+0x133 [C:\b\c\b\win64_clang\src\v8\src\heap\remembered-set.h @ 145] 
0b 0000008d`569ff5f0 00007ffa`364ae0f1 chrome_child!v8::internal::Scavenger::ScavengePage+0x290 [C:\b\c\b\win64_clang\src\v8\src\heap\scavenger.cc @ 102] 
0c (Inline Function) --------`-------- chrome_child!v8::internal::PageScavengingItem::Process+0x9 [C:\b\c\b\win64_clang\src\v8\src\heap\heap.cc @ 1931] 
0d 0000008d`569ff770 00007ffa`364adeea chrome_child!v8::internal::ScavengingTask::RunInParallel+0x1f1 [C:\b\c\b\win64_clang\src\v8\src\heap\heap.cc @ 1956] 
0e 0000008d`569ff8b0 00007ffa`35e787ff chrome_child!v8::internal::ItemParallelJob::Task::RunInternal+0x5a [C:\b\c\b\win64_clang\src\v8\src\heap\item-parallel-job.cc @ 45] 
0f (Inline Function) --------`-------- chrome_child!base::OnceCallback<void ()>::Run+0x16 [C:\b\c\b\win64_clang\src\base\callback.h @ 95] 
10 0000008d`569ff8f0 00007ffa`361ff681 chrome_child!base::debug::TaskAnnotator::RunTask+0xdf [C:\b\c\b\win64_clang\src\base\debug\task_annotator.cc @ 61] 
11 0000008d`569ffa10 00007ffa`361ff132 chrome_child!base::internal::TaskTracker::RunOrSkipTask+0x3a1 [C:\b\c\b\win64_clang\src\base\task_scheduler\task_tracker.cc @ 461] 
12 0000008d`569ffbb0 00007ffa`35e6df4c chrome_child!base::internal::TaskTracker::RunAndPopNextTask+0x102 [C:\b\c\b\win64_clang\src\base\task_scheduler\task_tracker.cc @ 355] 
13 0000008d`569ffd80 00007ffa`373a5785 chrome_child!base::internal::SchedulerWorker::Thread::ThreadMain+0x1ac [C:\b\c\b\win64_clang\src\base\task_scheduler\scheduler_worker.cc @ 85] 
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\System32\KERNEL32.DLL - 
14 0000008d`569ffea0 00007ffa`874e1fe4 chrome_child!base::`anonymous namespace'::ThreadFunc+0xf5 [C:\b\c\b\win64_clang\src\base\threading\platform_thread_win.cc @ 94] 
15 0000008d`569fff20 00007ffa`8761efc1 KERNEL32!BaseThreadInitThunk+0x14
16 0000008d`569fff50 00000000`00000000 ntdll!RtlUserThreadStart+0x21

I see
var var_Array_78 = Object.getOwnPropertyNames(var_Uint8ClampedArray_11);
var_Array_78.shift();

Looks like a left-trimming issue again.

I wonder it if is an instance of  crbug.com/831984 

Camillo, is getOwnPropertyNames also affected by  crbug.com/831984 ?

I can reproduce the crash before the fix for  crbug.com/831984 :
https://chromium.googlesource.com/v8/v8/+/7bb79b96bdd29c41acc8cf36c428dd66308e5b66

I cannot reproduce it after the fix. I also see that the test exercises KeyAccumulator::AddKey. So it is most likely the same issue.


#
# Fatal error in ../../src/heap/heap-inl.h, line 331
# Debug check failed: !result || gc_state_ != NOT_IN_GC || InToSpace(object).
#
#
#
#FailureMessage Object: 0x7ffffff04db0
==== C stack trace ===============================

    v8/out/x64.debug/./libv8_libbase.so(v8::base::debug::StackTrace::StackTrace()+0x1e) [0x7ffff7fb17ee]
    v8/out/x64.debug/./libv8_libplatform.so(+0x308c7) [0x7ffff7f508c7]
    v8/out/x64.debug/./libv8_libbase.so(V8_Fatal(char const*, int, char const*, ...)+0x21b) [0x7ffff7f997cb]
    v8/out/x64.debug/./libv8_libbase.so(+0x2c1ef) [0x7ffff7f991ef]
    v8/out/x64.debug/./libv8_libbase.so(V8_Dcheck(char const*, int, char const*)+0x32) [0x7ffff7f998b2]
    v8/out/x64.debug/d8(v8::internal::Heap::InNewSpace(v8::internal::MaybeObject*)+0xc3) [0x5555555c7cd3]
    v8/out/x64.debug/d8(v8::internal::Heap::InNewSpace(v8::internal::Object*)+0x68) [0x5555555c7d58]
    v8/out/x64.debug/./libv8.so(+0x175aeab) [0x7ffff6ed9eab]
    v8/out/x64.debug/./libv8.so(+0x175ad83) [0x7ffff6ed9d83]
    v8/out/x64.debug/./libv8.so(void v8::internal::BodyDescriptorBase::IteratePointers<v8::internal::ObjectVisitor>(v8::internal::HeapObject*, int, int, v8::internal::ObjectVisitor*)+0x67) [0x7ffff6ef32f7]
    v8/out/x64.debug/./libv8.so(void v8::internal::FlexibleBodyDescriptor<16>::IterateBody<v8::internal::ObjectVisitor>(v8::internal::Map*, v8::internal::HeapObject*, int, v8::internal::ObjectVisitor*)+0x2e) [0x7ffff6ef79ae]
    v8/out/x64.debug/./libv8.so(void v8::internal::CallIterateBody::apply<v8::internal::FlexibleBodyDescriptor<16>, v8::internal::ObjectVisitor>(v8::internal::Map*, v8::internal::HeapObject*, int, v8::internal::ObjectVisitor*)+0x2b) [0x7ffff6ef740b]
    v8/out/x64.debug/./libv8.so(void v8::internal::BodyDescriptorApply<v8::internal::CallIterateBody, void, v8::internal::Map*, v8::internal::HeapObject*, int, v8::internal::ObjectVisitor*>(v8::internal::InstanceType, v8::internal::Map*, v8::internal::HeapObject*, int, v8::internal::ObjectVisitor*)+0x14a) [0x7ffff712e28a]
    v8/out/x64.debug/./libv8.so(void v8::internal::HeapObject::IterateBodyFast<v8::internal::ObjectVisitor>(v8::internal::Map*, int, v8::internal::ObjectVisitor*)+0x3f) [0x7ffff711a28f]
    v8/out/x64.debug/./libv8.so(void v8::internal::HeapObject::IterateBodyFast<v8::internal::ObjectVisitor>(v8::internal::ObjectVisitor*)+0x4f) [0x7ffff712e12f]
    v8/out/x64.debug/./libv8.so(void v8::internal::HeapObject::IterateFast<v8::internal::ObjectVisitor>(v8::internal::ObjectVisitor*)+0x35) [0x7ffff711a245]
    v8/out/x64.debug/./libv8.so(v8::internal::HeapObject::Iterate(v8::internal::ObjectVisitor*)+0x1d) [0x7ffff70b7acd]
    v8/out/x64.debug/./libv8.so(+0x175b650) [0x7ffff6eda650]
    v8/out/x64.debug/./libv8.so(+0x175b469) [0x7ffff6eda469]
    v8/out/x64.debug/./libv8.so(+0x174ddd2) [0x7ffff6eccdd2]
    v8/out/x64.debug/./libv8.so(v8::internal::MarkCompactCollector::EnsureSweepingCompleted()+0xe1) [0x7ffff6eccd31]
    v8/out/x64.debug/./libv8.so(v8::internal::Heap::Verify()+0x7f) [0x7ffff6e6d1bf]
    v8/out/x64.debug/./libv8.so(v8::internal::Heap::GarbageCollectionEpilogue()+0x16d) [0x7ffff6e6ffbd]
    v8/out/x64.debug/./libv8.so(v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)+0x385) [0x7ffff6e72875]
    v8/out/x64.debug/./libv8.so(v8::internal::Heap::CollectAllGarbage(int, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)+0x39) [0x7ffff6e71439]
    v8/out/x64.debug/./libv8.so(v8::internal::Heap::HandleGCRequest()+0xe8) [0x7ffff6e71368]
    v8/out/x64.debug/./libv8.so(v8::internal::StackGuard::HandleInterrupts()+0x87) [0x7ffff6dd87c7]
    v8/out/x64.debug/./libv8.so(+0x1baac90) [0x7ffff7329c90]
    v8/out/x64.debug/./libv8.so(v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*)+0x107) [0x7ffff7329937]

Is there anything left to do before declaring this a duplicate of 831984?

So it looks like this is a known issue?
Then will the CVE number be assigned to this question?

Yes getOwnPropertyNames also goes through the KeyAccumulator and would be affected in the same way.
I will check tomorrow that it is indeed the same issue.

Thanks for holding it.

Just found some time to look into this, ulan's observations are correct.
I confirm this being the same issue.

The NextAction date has arrived: 2018-05-03

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