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

Issue 460917 link

Starred by 3 users

Issue metadata

Status: Verified
Closed: Mar 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Sign in to add a comment

OOB write in v8 due to elements kind confusion

Reported by, Feb 23 2015

Issue description

Chrome Version       : 42.0.2311.0 (Developer Build) (64-bit)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 7.1.3: OK
  Firefox 35.0.1: OK
       IE 7/8/9/10: N/A

What steps will reproduce the problem?
1. Turn on a specific graphics feature (section plane view) in our WebGL-based software (
2. Manipulate the view, rotate the camera, etc.
3. Shortly after, sometimes an Aw Snap tab crash will happen.

What is the expected result?

Tab doesn't crash

What happens instead?

Tab crashes (Aw Snap)

Please provide any additional information below. Attach a screenshot if

I apologize that this report does not include solid repro steps. This is a rare crash that feels like a race condition and occurs perhaps 1 of 5-10 times a specific visualization mode is used. Unfortunately the software itself ( is also closed for a little while longer, but if anyone would like to work on this bug I can provide an invitation. 

This bug appears on Mac and Windows in the latest Chrome and Chromium. 

I have managed to trap the crash in Xcode in a debug Chromium build. It appears that somehow the internal v8 javascript function handle for the requestAnimationFrame callback becomes NULL. I have seen it crash the same way twice in the debugger. The crash is definitely triggered by a specific WebGL graphics feature (section view) that shows a cutaway of the model, though the causal link there is mysterious. 

I have attached a screenshot of the debugger stopped at the offending line.

The about version information is:

Chromium	42.0.2311.0 (Developer Build) (64-bit)
Revision	ca068183ed1ef472599cbd1acb69d954d7a3b635-refs/heads/master@{#317350}
OS	Mac OS X 
Blink	537.36 (@190452)
JavaScript	V8 4.2.77
Flash	(Disabled)
User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.0 Safari/537.36
Command Line	/Users/fcole/chromium/src/out/Debug/ --disable-background-networking --disable-client-side-phishing-detection --disable-component-update --disable-default-apps --disable-hang-monitor --disable-prompt-on-repost --disable-sync --disable-web-resources --enable-logging --ignore-certificate-errors --ignore-gpu-blacklist --enable-logging --v=1 --load-extension=/var/folders/pf/llj71sj90r30369h0pnfgrn40000gn/T/.org.chromium.Chromium.sc8Vm8/internal --log-level=0 --metrics-recording-only --no-first-run --password-store=basic --remote-debugging-port=12997 --safebrowsing-disable-auto-update --safebrowsing-disable-download-protection --test-type=webdriver --use-mock-keychain --user-data-dir=/var/folders/pf/llj71sj90r30369h0pnfgrn40000gn/T/.org.chromium.Chromium.fLrNZY --enable-avfoundation --flag-switches-begin --flag-switches-end data:,
Executable Path	/Users/fcole/chromium/src/out/Debug/
Profile Path	/private/var/folders/pf/llj71sj90r30369h0pnfgrn40000gn/T/.org.chromium.Chromium.fLrNZY/Default
Variations	InfiniteCache:No
624 KB View Download

Comment 1 by, Feb 23 2015

Labels: OS-Mac Stability-Crash

Comment 2 by, Feb 23 2015

Labels: Cr-Blink-Animation
@fcole, could you provide a crash id from chrome://crashes?
Labels: Needs-Feedback

Comment 5 by, Feb 23 2015

Sorry, I somehow thought that crash ids were only for crashes for the whole program. I just reran my test and got:

Crash ID 7ec4e9dfbe7cb48e (Chrome)

Occurred Monday, February 23, 2015 at 5:58:30 PM

Comment 6 by, Feb 25 2015

This is crash in invoke as per the stack trace of crash id 7ec4e9dfbe7cb48e.The crash id is from the chrome version:40.0.2214.115.

fcole@: Could you please confirm the chrome version where you are facing this issue.

Stack trace of 7ec4e9dfbe7cb48e :
Thread 0 CRASHED [EXC_BAD_ACCESS / 0x0000000d @ 0x00000000] MAGIC SIGNATURE THREAD
0x000000010e00dbfd	[Google Chrome Framework ]	v8::internal::Invoke(bool, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*)
0x000000010df02730	[Google Chrome Framework ]	v8::Function::Call(v8::Handle<v8::Value>, int, v8::Handle<v8::Value>*)
0x000000010eb94b2d	[Google Chrome Framework -V8ScriptRunner.cpp:231 ]	blink::V8ScriptRunner::callFunction(v8::Handle<v8::Function>, blink::ExecutionContext*, v8::Handle<v8::Value>, int, v8::Handle<v8::Value>*, v8::Isolate*)
0x000000010eb6208b	[Google Chrome Framework -ScriptController.cpp:171 ]	blink::ScriptController::callFunction(blink::ExecutionContext*, v8::Handle<v8::Function>, v8::Handle<v8::Value>, int, v8::Handle<v8::Value>*, v8::Isolate*)
0x000000010eced8ba	[Google Chrome Framework -V8RequestAnimationFrameCallback.cpp:47 ]	blink::V8RequestAnimationFrameCallback::handleEvent(double)
0x000000010e3db11e	[Google Chrome Framework -ScriptedAnimationController.cpp:188 ]	blink::ScriptedAnimationController::executeCallbacks(double)
0x000000010e3db309	[Google Chrome Framework -ScriptedAnimationController.cpp:220 ]	blink::ScriptedAnimationController::serviceScriptedAnimations(double)
0x000000010e89def8	[Google Chrome Framework -PageAnimator.cpp:66 ]	blink::PageAnimator::serviceScriptedAnimations(double)
0x000000010e2f7e28	[Google Chrome Framework -PageWidgetDelegate.cpp:56 ]	blink::PageWidgetDelegate::animate(blink::Page&, double, blink::LocalFrame&)
0x000000010e34bbc4	[Google Chrome Framework -WebViewImpl.cpp:1878 ]	blink::WebViewImpl::beginFrame(blink::WebBeginFrameArgs const&)
0x00000001102d7f61	[Google Chrome Framework ]	non-virtual thunk to content::RenderWidgetCompositor::BeginMainFrame(cc::BeginFrameArgs const&)
0x000000010d808d09	[Google Chrome Framework ]	cc::LayerTreeHost::BeginMainFrame(cc::BeginFrameArgs const&)
0x000000010d834b3c	[Google Chrome Framework ]	cc::ThreadProxy::BeginMainFrame(scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >)
0x000000010d838d27	[Google Chrome Framework -bind_internal.h:190 ]	base::internal::InvokeHelper<true, void, base::internal::RunnableAdapter<void (cc::ThreadProxy::*)(scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >)>, void (base::WeakPtr<cc::ThreadProxy> const&, scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >)>::MakeItSo(base::internal::RunnableAdapter<void (cc::ThreadProxy::*)(scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >)>, base::WeakPtr<cc::ThreadProxy> const&, scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >)
0x000000010d838c84	[Google Chrome Framework -bind_internal.h:1248 ]	base::internal::Invoker<2, base::internal::BindState<base::internal::RunnableAdapter<void (cc::ThreadProxy::*)(scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >)>, void (cc::ThreadProxy*, scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >), void (base::WeakPtr<cc::ThreadProxy>, base::internal::PassedWrapper<scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> > >)>, void ()(cc::ThreadProxy*, scoped_ptr<cc::ThreadProxy::BeginMainFrameAndCommitState, base::DefaultDeleter<cc::ThreadProxy::BeginMainFrameAndCommitState> >)>::Run(base::internal::BindStateBase*)
0x000000010cce1f43	[Google Chrome Framework -callback.h:401 ]	base::debug::TaskAnnotator::RunTask(char const*, char const*, base::PendingTask const&)
0x000000010cd1381e	[Google Chrome Framework ]	base::MessageLoop::RunTask(base::PendingTask const&)
0x000000010cd13c3e	[Google Chrome Framework ]	base::MessageLoop::DoWork()
0x000000010cccbfc0	[Google Chrome Framework ]	base::MessagePumpCFRunLoopBase::RunWork()
0x00007fff91e585b0	[CoreFoundation + 0x0007f5b0 ]	__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
0x00007fff91e49c61	[CoreFoundation + 0x00070c61 ]	__CFRunLoopDoSources0
0x00007fff91e493ee	[CoreFoundation + 0x000703ee ]	__CFRunLoopRun
0x00007fff91e48e74	[CoreFoundation + 0x0006fe74 ]	CFRunLoopRunSpecific
0x00007fff89f5916b	[Foundation + 0x0006916b ]	-[NSRunLoop(NSRunLoop) runMode:beforeDate:]
0x000000010cccc423	[Google Chrome Framework ]	base::MessagePumpNSRunLoop::DoRun(base::MessagePump::Delegate*)
0x000000010cccbe2b	[Google Chrome Framework ]	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x000000010cd28ab2	[Google Chrome Framework ]	base::RunLoop::Run()
0x000000010cd1313c	[Google Chrome Framework ]	base::MessageLoop::Run()
0x000000011035c97f	[Google Chrome Framework ]	content::RendererMain(content::MainFunctionParams const&)
0x000000010ccae553	[Google Chrome Framework ]	content::ContentMainRunnerImpl::Run()
0x000000010ccadba5	[Google Chrome Framework ]	content::ContentMain(content::ContentMainParams const&)
0x000000010c6483f1	[Google Chrome Framework ]	ChromeMain
0x000000010c63ff38	[Google Chrome Helper ]	main
0x000000010c63ff23	[Google Chrome Helper + 0x00000f23 ]	start

Comment 7 by, Feb 25 2015

I can provoke the crash both in Chrome and Chromium. I was debugging it in Chromium, but I submitted the crash report from my system Chrome because apparently crash reporting is disabled in Chromium (that's the message on chrome://crashes at least). 

We've also seen this issue intermittently for a while (months) on windows and mac, and different versions of Chrome. I can't be certain it's the same crash but the symptoms are the same.

Comment 8 by, Feb 25 2015

Do you have a reduced test case that we could try?

Comment 9 by, Feb 25 2015

The best I can do is give you access to the system with a small model. I have sent an invitation to Please let me know if you receive it. I can also invite anyone else who needs to look at this issue.

I have added a google doc with repro steps and a link to a small model here:

Comment 10 by, Mar 3 2015

Have you guys had any luck reproducing this issue? Please let me know if I can help provide any more information.
I was not able to reproduce the issue, sorry. It would be very helpful if you could create an isolated test case file that minimizes the reproducible issue.

Comment 12 by, Mar 3 2015

Thanks for the quick response. Do you mean you were able to run the steps I suggested and the crash did not occur, or you were not able to run the steps? 

I will think some more about how to try to isolate this, though it is a difficult problem since the issue only appears in a fairly complex case. I will also try with the latest Chromium.
If you can still repro on the latest Canary or Chromium, what I'd do is save the entire page (File > Save Page As > Web Page, Complete), and then start removing resources and code while it still reproduces.

Comment 14 by, Mar 3 2015

Unfortunately, it's not that simple to produce a simple test case. The system is a cloud-based CAD modeling system and it loads geometry over a socket connection for rendering. The crash happens when rendering graphics after a lot of socket communication has occurred. While theoretically possible, it isn't practical for us right now to engineer a version that will run standalone in a page. 

For what it's worth, it still reproduces using the steps I put in the google doc above.

Comment 16 by, Mar 9 2015

Labels: -Pri-2 Pri-1 OS-Linux Cr-Blink-JavaScript Security_Severity-High Restrict-View-SecurityNotify
Status: Assigned
@jkummerow and I have both reproduced this, him on 32-bit Linux, me on 64-bit Mac. Jakob has triaged it to a good degree though the root cause is not known yet. Jakob, may I assign this to you for further investigation?

Restricting view because the nature of the crash appears to be a possible security issue.

Yes, I'll look; however I won't have much time this week.

fcole, if you do happen to come across an easier or more reliable way to reproduce this, I'd love to hear about it (would make it easier to bisect, or test if various flags have any impact); but I can also work with the repro we have.
Labels: -OS-Mac -Cr-Blink-Animation -Needs-Feedback -OS-Linux OS-All Security_Impact-Stable
As I suspected: elements kind confusion leading to invalid stores into arrays. On 32-bit platforms this can be an out-of-bounds store (depending on index). On 64-bit it'll "just" cause corruption (however over lunch we just came up with an idea for a few intermediate steps that can probably turn it into an arbitrary OOB write as well). The issue is triggered by having two HValues referring to the same array, and having one of them transition the array's elements kind, which the other doesn't realize.


function boom(a1, a2) {
  // Do something with a2 that needs a map check (for DOUBLE_ELEMENTS).
  var s = a2[0];
  // Emit a load that transitions a1 to FAST_ELEMENTS.
  var t = a1[0];
  // Emit a store to a2 that assumes DOUBLE_ELEMENTS.
  // The map check is considered redundant and will be eliminated.
  a2[0] = 0.3;

// Prepare type feedback for the "t = a1[0]" load: fast elements.
var fast_elem = new Array(1);
fast_elem[0] = "tagged";
boom(fast_elem, [1]);

// Prepare type feedback for the "a2[0] = 0.3" store: double elements.
var double_elem = new Array(1);
double_elem[0] = 0.1;
boom(double_elem, double_elem);

// Reset |double_elem| and go have a party.
double_elem = new Array(10);
double_elem[0] = 0.1;

boom(double_elem, double_elem);

assertEquals(0.3, double_elem[0]);
assertEquals(undefined, double_elem[1]);

--nocheck-elimination fixes it. Probably what we need to do is in HCheckElimination, whenever an HTransitionElementsKind is seen, discard all knowledge about all HValues with JSArray maps.

Igor offered to take a look. Thanks!

We've had this bug for about a year now, so once we have a fix it should be backmerged to all channels.
Labels: -Type-Bug -Restrict-View-SecurityNotify Type-Bug-Security Restrict-View-SecurityTeam
Summary: OOB write in v8 due to elements kind confusion (was: Rare CrRendererMain crash in V8RequestAnimationFrameCallback)
Project Member

Comment 20 by ClusterFuzz, Mar 11 2015

Labels: M-41

Comment 21 by, Mar 11 2015

Excellent diagnosis Jakob. Thank you for getting to the bottom of this and for coming up with a minimized reproduction.

Status: Fixed
Project Member

Comment 24 by ClusterFuzz, Mar 12 2015

Labels: M-42 Merge-Triage
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
Labels: -Merge-Triage Merge-Requested
Merge Requested for M42

Comment 26 by, Mar 16 2015

Labels: -Merge-Requested Merge-Review Hotlist-Merge-Review
[Automated comment] Request affecting a post-stable build (M41), manual review required.

Comment 27 by, Mar 16 2015

Labels: Merge-Approved Hotlist-Merge-Approved
Approved for M42 (branch: 2311)
Note that we don't have good Canary coverage yet (due to a V8 revert over the weekend).
OK - in that case, best to hold off for a few days and then land the merge at a later time.
Project Member

Comment 30 by, Mar 19 2015

Labels: -Merge-Review -Hotlist-Merge-Review

Comment 33 by, Apr 1 2015

Just saw that this update made it into the stable branch. Tested on my machine and I can no longer produce the crash. Thanks all!
Status: Verified
#33: Thanks for reporting back; glad to hear that the fix indeed resolves the crashes you were seeing.

Also, thanks again for reporting this issue in the first place, and for providing the repro! As you can see from the discussion above, this was quite an important bug for us to find and fix.
Labels: Release-2-M41 reward-topanel
Labels: -reward-topanel reward-unpaid reward-500 CVE-2015-1242
Congratulations - our reward panel has decided to award you $500 for your help here!

Someone from our finance area should be in contact in two weeks to collect payment details. Please contact me directly if this doesn't happen.

We'll credit you in our release notes as "" (this will go out in our M42 release notes, even though it was fixed earlier). Please let me know if you'd like to use another name or handle.


*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Comment 37 by, Apr 14 2015

Wow, that's generous. Thanks! Happy to help and thanks again for fixing the bug, it's saved me a lot of headache.
Labels: -reward-unpaid reward-inprocess
Project Member

Comment 39 by ClusterFuzz, Jun 18 2015

Labels: -Restrict-View-SecurityTeam
Bulk update: removing view restriction from closed bugs.
Labels: -reward-inprocess
Processing via our e-payment system can take up to two weeks, but the reward should be on its way to you. Thanks again for your help!
Labels: -reward-500 -Hotlist-Merge-Approved Reward-500
Project Member

Comment 42 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 43 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