Issue metadata
Sign in to add a comment
|
The browser crashed caused by global-buffer-overflow.And d8 crashed caused by segv.
Reported by
cdsrc2...@gmail.com,
Jan 20 2017
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Steps to reproduce the problem:
1. launch chromium with these flags．> ./chrome --js-flags="--allow-natives-syntax" --no-sandbox ./crash.html
or,
launch d8 with these flags.> ./d8 --allow-natives-syntax ./crash.js
It would not crash everytime, so you should test for a couple of times.
What is the expected behavior?
What went wrong?
he browser crashed caused by global-buffer-overflow.And d8 crashed caused by segv.
When we test for this issue, we found that the browser dumped different crash logs with the same input file.
1. d8
==16816==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x563e6aae8f11 bp 0x7ffef5718fc0 sp 0x7ffef5718f80 T0)
==16816==The signal is caused by a READ memory access.
==16816==Hint: address points to the zero page.
#0 0x563e6aae8f10 in FromAddress ./out/d8-asan-ubsan/../../v8/src/heap/spaces.h:679:53
#1 0x563e6aae8f10 in RecordSlot ./out/d8-asan-ubsan/../../v8/src/heap/mark-compact-inl.h:63:0
#2 0x563e6aae8f10 in VisitPointer ./out/d8-asan-ubsan/../../v8/src/heap/incremental-marking.cc:243:0
#3 0x563e6aae8f10 in VisitTransitionArray ./out/d8-asan-ubsan/../../v8/src/heap/objects-visiting-inl.h:367:0
#4 0x563e6aae6da3 in IterateBody ./out/d8-asan-ubsan/../../v8/src/heap/objects-visiting.h:358:5
#5 0x563e6aae6da3 in VisitObject ./out/d8-asan-ubsan/../../v8/src/heap/incremental-marking.cc:843:0
#6 0x563e6aae6da3 in ProcessMarkingDeque ./out/d8-asan-ubsan/../../v8/src/heap/incremental-marking.cc:890:0
#7 0x563e6aae6da3 in Step ./out/d8-asan-ubsan/../../v8/src/heap/incremental-marking.cc:1166:0
#8 0x563e6aae69a8 in AdvanceIncrementalMarking ./out/d8-asan-ubsan/../../v8/src/heap/incremental-marking.cc:1064:7
#9 0x563e6aae3d26 in Step ./out/d8-asan-ubsan/../../v8/src/heap/incremental-marking-job.cc:37:32
#10 0x563e6aae3d26 in RunInternal ./out/d8-asan-ubsan/../../v8/src/heap/incremental-marking-job.cc:57:0
#11 0x563e6b0940ee in PumpMessageLoop ./out/d8-asan-ubsan/../../v8/src/libplatform/default-platform.cc:161:9
#12 0x563e6a55f64e in EmptyMessageQueues ./out/d8-asan-ubsan/../../v8/src/d8.cc:2599:12
#13 0x563e6a55f64e in ExecuteString ./out/d8-asan-ubsan/../../v8/src/d8.cc:530:0
#14 0x563e6a566a8c in Execute ./out/d8-asan-ubsan/../../v8/src/d8.cc:2068:10
#15 0x563e6a56857
Did this work before? N/A
Chrome version: 55.0.2883.87 Channel: stable
OS Version: Ubuntu 14.04.5
Flash Version:
,
Jan 20 2017
fix log: v8 version:5.7.496 chrome version:57.0.2986.0 canary
,
Jan 23 2017
Over to the V8 sheriff
,
Jan 23 2017
Not a ClusterFuzz bug, reassigning to V8 stability sheriff.
,
Jan 23 2017
,
Jan 23 2017
,
Jan 23 2017
,
Jan 23 2017
Unfortunately I can't reproduce this. Using the stable version, I get a SyntaxError because the runtime function used to take only one argument. Using the canary version, I get a CHECK failure because the runtime function is used in an invalid way (such functions should not be called from user code).
,
Jan 23 2017
Just to clarify, by runtime function I'm referring to %NewFunctionContext.
,
Jan 23 2017
As mentioned, this issue will not be reproduced every times.Maybe you need to try a few more times.I tested many times,and I got these type of feedbacks.
1. ./d8 --allow-natives-syntax ./crash.js
./crash.js:8: RangeError: Maximum call stack size exceeded
this[255] = new Int32Array(new Array(0xff000000,0xfffc,-65536,-32767,65535,128))
^
RangeError: Maximum call stack size exceeded
at Proxy.f2880 (./crash.js:8:16)
at JSON.parse (<anonymous>)
at ./crash.js:32:6
2. ./d8 --allow-natives-syntax ./crash.js
ASAN:DEADLYSIGNAL
=================================================================
==13817==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55f9ff45bff1 bp 0x7fff3434f9a0 sp 0x7fff3434f950 T0)
==13817==The signal is caused by a READ memory access.
==13817==Hint: address points to the zero page.
#0 0x55f9ff45bff0 in FromAddress v8/src/heap/spaces.h:679:53
#1 0x55f9ff45bff0 in RecordSlot v8/src/heap/mark-compact-inl.h:63
#2 0x55f9ff45bff0 in MarkObjectByPointer v8/src/heap/mark-compact.cc:1159
#3 0x55f9ff45bff0 in VisitPointer v8/src/heap/mark-compact.cc:1120
#4 0x55f9ff45bff0 in v8::internal::StaticMarkingVisitor<v8::internal::MarkCompactMarkingVisitor>::VisitTransitionArray(v8::internal::Map*, v8::internal::HeapObject*) v8/src/heap/objects-visiting-inl.h:367
#5 0x55f9ff438da3 in IterateBody v8/src/heap/objects-visiting.h:358:5
#6 0x55f9ff438da3 in VisitObject v8/src/heap/incremental-marking.cc:843
#7 0x55f9ff438da3 in ProcessMarkingDeque v8/src/heap/incremental-marking.cc:890
#8 0x55f9ff438da3 in v8::internal::IncrementalMarking::Step(unsigned long, v8::internal::IncrementalMarking::CompletionAction, v8::internal::IncrementalMarking::ForceCompletionAction, v8::internal::StepOrigin) v8/src/heap/incremental-marking.cc:1166
#9 0x55f9ff4389a8 in v8::internal::IncrementalMarking::AdvanceIncrementalMarking(double, v8::internal::IncrementalMarking::CompletionAction, v8::internal::IncrementalMarking::ForceCompletionAction, v8::internal::StepOrigin) v8/src/heap/incremental-marking.cc:1064:7
#10 0x55f9ff435d26 in Step v8/src/heap/incremental-marking-job.cc:37:32
#11 0x55f9ff435d26 in v8::internal::IncrementalMarkingJob::Task::RunInternal() v8/src/heap/incremental-marking-job.cc:57
#12 0x55f9ff9e60ee in v8::platform::DefaultPlatform::PumpMessageLoop(v8::Isolate*) v8/src/libplatform/default-platform.cc:161:9
#13 0x55f9feeb164e in EmptyMessageQueues v8/src/d8.cc:2599:12
#14 0x55f9feeb164e in v8::Shell::ExecuteString(v8::Isolate*, v8::Local<v8::String>, v8::Local<v8::Value>, bool, bool) v8/src/d8.cc:530
#15 0x55f9feeb8a8c in v8::SourceGroup::Execute(v8::Isolate*) v8/src/d8.cc:2068:10
#16 0x55f9feeba57f in v8::Shell::RunMain(v8::Isolate*, int, char**, bool) v8/src/d8.cc:2564:34
#17 0x55f9feebe9bb in v8::Shell::Main(int, char**) v8/src/d8.cc:3046:16
#18 0x7ff7a07adf44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV v8/src/heap/spaces.h:679:53 in FromAddress
,
Jan 23 2017
3. ./d8 --allow-natives-syntax ./crash.js
ASAN:DEADLYSIGNAL
=================================================================
==17185==ERROR: AddressSanitizer: SEGV on unknown address 0x7f54fbd82340 (pc 0x55e2fee32c24 bp 0x7fffd8094260 sp 0x7fffd8094230 T0)
==17185==The signal is caused by a READ memory access.
#0 0x55e2fee32c23 in VisitCodeTarget v8/src/heap/objects-visiting-inl.h:265:7
#1 0x55e2fee32c23 in void v8::internal::RelocInfo::Visit<v8::internal::MarkCompactMarkingVisitor>(v8::internal::Heap*) v8/src/x64/assembler-x64-inl.h:541
#2 0x55e2fee3153a in IterateBody<v8::internal::MarkCompactMarkingVisitor> v8/src/objects-body-descriptors-inl.h:419:28
#3 0x55e2fee3153a in IterateBody<v8::internal::MarkCompactMarkingVisitor> v8/src/objects-body-descriptors-inl.h:425
#4 0x55e2fee3153a in Visit v8/src/heap/objects-visiting.h:208
#5 0x55e2fee3153a in v8::internal::StaticMarkingVisitor<v8::internal::MarkCompactMarkingVisitor>::VisitCode(v8::internal::Map*, v8::internal::HeapObject*) v8/src/heap/objects-visiting-inl.h:420
#6 0x55e2fee0eda3 in IterateBody v8/src/heap/objects-visiting.h:358:5
#7 0x55e2fee0eda3 in VisitObject v8/src/heap/incremental-marking.cc:843
#8 0x55e2fee0eda3 in ProcessMarkingDeque v8/src/heap/incremental-marking.cc:890
#9 0x55e2fee0eda3 in v8::internal::IncrementalMarking::Step(unsigned long, v8::internal::IncrementalMarking::CompletionAction, v8::internal::IncrementalMarking::ForceCompletionAction, v8::internal::StepOrigin) v8/src/heap/incremental-marking.cc:1166
#10 0x55e2fee0e9a8 in v8::internal::IncrementalMarking::AdvanceIncrementalMarking(double, v8::internal::IncrementalMarking::CompletionAction, v8::internal::IncrementalMarking::ForceCompletionAction, v8::internal::StepOrigin) v8/src/heap/incremental-marking.cc:1064:7
#11 0x55e2fee0bd26 in Step v8/src/heap/incremental-marking-job.cc:37:32
#12 0x55e2fee0bd26 in v8::internal::IncrementalMarkingJob::Task::RunInternal() v8/src/heap/incremental-marking-job.cc:57
#13 0x55e2ff3bc0ee in v8::platform::DefaultPlatform::PumpMessageLoop(v8::Isolate*) v8/src/libplatform/default-platform.cc:161:9
#14 0x55e2fe88764e in EmptyMessageQueues v8/src/d8.cc:2599:12
#15 0x55e2fe88764e in v8::Shell::ExecuteString(v8::Isolate*, v8::Local<v8::String>, v8::Local<v8::Value>, bool, bool) v8/src/d8.cc:530
#16 0x55e2fe88ea8c in v8::SourceGroup::Execute(v8::Isolate*) v8/src/d8.cc:2068:10
#17 0x55e2fe89057f in v8::Shell::RunMain(v8::Isolate*, int, char**, bool) v8/src/d8.cc:2564:34
#18 0x55e2fe8949bb in v8::Shell::Main(int, char**) v8/src/d8.cc:3046:16
#19 0x7f559bb5ef44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV v8/src/heap/objects-visiting-inl.h:265:7 in VisitCodeTarget
4. ./d8 --allow-natives-syntax ./crash.js
ASAN:DEADLYSIGNAL
=================================================================
==17251==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000038f (pc 0x564db725ff24 bp 0x7ffc96a9b290 sp 0x7ffc96a9b270 T0)
==17251==The signal is caused by a READ memory access.
==17251==Hint: address points to the zero page.
#0 0x564db725ff23 in v8::internal::ScavengingVisitor<(v8::internal::MarksHandling)0, (v8::internal::LoggingAndProfiling)1>::EvacuateFixedArray(v8::internal::Map*, v8::internal::HeapObject**, v8::internal::HeapObject*) v8/src/heap/scavenger.cc:257
#1 0x564db7218da3 in IterateBody v8/src/heap/objects-visiting.h:358:5
#2 0x564db7218da3 in VisitObject v8/src/heap/incremental-marking.cc:843
#3 0x564db7218da3 in ProcessMarkingDeque v8/src/heap/incremental-marking.cc:890
#4 0x564db7218da3 in v8::internal::IncrementalMarking::Step(unsigned long, v8::internal::IncrementalMarking::CompletionAction, v8::internal::IncrementalMarking::ForceCompletionAction, v8::internal::StepOrigin) v8/src/heap/incremental-marking.cc:1166
#5 0x564db72189a8 in v8::internal::IncrementalMarking::AdvanceIncrementalMarking(double, v8::internal::IncrementalMarking::CompletionAction, v8::internal::IncrementalMarking::ForceCompletionAction, v8::internal::StepOrigin) v8/src/heap/incremental-marking.cc:1064:7
#6 0x564db7215d26 in Step v8/src/heap/incremental-marking-job.cc:37:32
#7 0x564db7215d26 in v8::internal::IncrementalMarkingJob::Task::RunInternal() v8/src/heap/incremental-marking-job.cc:57
#8 0x564db77c60ee in v8::platform::DefaultPlatform::PumpMessageLoop(v8::Isolate*) v8/src/libplatform/default-platform.cc:161:9
#9 0x564db6c9164e in EmptyMessageQueues v8/src/d8.cc:2599:12
#10 0x564db6c9164e in v8::Shell::ExecuteString(v8::Isolate*, v8::Local<v8::String>, v8::Local<v8::Value>, bool, bool) v8/src/d8.cc:530
#11 0x564db6c98a8c in v8::SourceGroup::Execute(v8::Isolate*) v8/src/d8.cc:2068:10
#12 0x564db6c9a57f in v8::Shell::RunMain(v8::Isolate*, int, char**, bool) v8/src/d8.cc:2564:34
#13 0x564db6c9e9bb in v8::Shell::Main(int, char**) v8/src/d8.cc:3046:16
#14 0x7ff8d0748f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV v8/src/heap/scavenger.cc:257 in v8::internal::ScavengingVisitor<(v8::internal::MarksHandling)0, (v8::internal::LoggingAndProfiling)1>::EvacuateFixedArray(v8::internal::Map*, v8::internal::HeapObject**, v8::internal::HeapObject*)
==17251==ABORTING
,
Jan 23 2017
How are you building d8?
,
Jan 23 2017
just follow this site, https://dev.chromium.org/developers/testing/addresssanitizer. is_asan = true enable_nacl = false # Necessary until NaCl GN build is more complete. is_debug = false # Release build. And ninja -C out/d8-asan d8
,
Jan 23 2017
I was running asan too but my asan build had is_debug = true. After changing that to false, I consistenly get the RangeError:
$ d8 Asan --allow-natives-syntax crash.js
crash.js:8: RangeError: Maximum call stack size exceeded
this[255] = new Int32Array(new Array(0xff000000,0xfffc,-65536,-32767,65535,128))
^
RangeError: Maximum call stack size exceeded
at Proxy.f2880 crash.js:8:16)
at JSON.parse (<anonymous>)
at crash.js:32:6
Will investigate more tomorrow.
,
Jan 24 2017
One thing, I forgot to tell you, I built my d8 with another flag: "is_ubsan=true".I dont know whether this is the reason that you can't reproduce this issue. Maybe you can add this flag and rebuild d8.
,
Jan 24 2017
Sometimes I get a RangeError,but sometimes I get a segv on FromAddress.
,
Jan 24 2017
I was able to observe the segfault once, will investigate more.
,
Jan 24 2017
I'm pretty sure this is a consequence of the invalid use of an internal runtime function. Closing this as WontFix. Please reopen if you have a repro that does not use the natives-syntax feature.
,
May 2 2017
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
,
Jun 23 2017
Issue 736077 has been merged into this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by cdsrc2...@gmail.com
, Jan 20 2017chrome crash log: ==12215==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55c892a83ca8 at pc 0x55c87bce2b6c bp 0x7fffa06969d0 sp 0x7fffa06969c8 READ of size 8 at 0x55c892a83ca8 thread T0 (chrome) #0 0x55c87bce2b6b in GetVisitor ./out/asan-chrome/../../v8/src/heap/objects-visiting-inl.h:20:37 #1 0x55c87bce2b6b in IterateBody ./out/asan-chrome/../../v8/src/heap/objects-visiting.h:358:0 #2 0x55c87bce2b6b in VisitObject ./out/asan-chrome/../../v8/src/heap/incremental-marking.cc:843:0 #3 0x55c87bce2b6b in ProcessMarkingDeque ./out/asan-chrome/../../v8/src/heap/incremental-marking.cc:890:0 #4 0x55c87bce2b6b in Step ./out/asan-chrome/../../v8/src/heap/incremental-marking.cc:1166:0 #5 0x55c87bce361f in AdvanceIncrementalMarkingOnAllocation ./out/asan-chrome/../../v8/src/heap/incremental-marking.cc:1146:25 #6 0x55c87bdbd12a in AllocationStep ./out/asan-chrome/../../v8/src/heap/heap.h:2666:7 #7 0x55c87bdbd12a in InlineAllocationStep ./out/asan-chrome/../../v8/src/heap/spaces.cc:1807:0 #8 0x55c87bdbd12a in EnsureAllocation ./out/asan-chrome/../../v8/src/heap/spaces.cc:1750:0 #9 0x55c87bc226cf in AllocateRawUnaligned ./out/asan-chrome/../../v8/src/heap/spaces-inl.h:557:10 #10 0x55c87bc226cf in AllocateRaw ./out/asan-chrome/../../v8/src/heap/spaces-inl.h:581:0 #11 0x55c87bc226cf in AllocateRaw ./out/asan-chrome/../../v8/src/heap/heap-inl.h:318:0 #12 0x55c87bc98d87 in AllocateFillerObject ./out/asan-chrome/../../v8/src/heap/heap.cc:2100:35 #13 0x55c87bbd4ebe in NewFillerObject ./out/asan-chrome/../../v8/src/factory.cc:85:3 #14 0x55c87c48ff7b in __RT_impl_Runtime_AllocateInNewSpace ./out/asan-chrome/../../v8/src/runtime/runtime-internal.cc:281:31 #15 0x55c87c48ff7b in Runtime_AllocateInNewSpace ./out/asan-chrome/../../v8/src/runtime/runtime-internal.cc:274:0 #7 0x7fb4c9c04426 (<unknown module>) #8 0x7fb4c9c05716 (<unknown module>) #9 0x7fb4c9c5214b (<unknown module>) #10 0x7fb4c9d0f0fa (<unknown module>) #11 0x7fb4c9cc608d (<unknown module>) #12 0x7fb4c9ca1a1c (<unknown module>) #13 0x7fb4c9c05954 (<unknown module>) #14 0x7fb4c9ca0aa2 (<unknown module>) #15 0x7fb4c9c2d5a0 (<unknown module>)