989210 - (CVE-2014-1525) Heap-use-after-free in mozilla::dom::TextTrack::AddCue

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Abhishek Arya]

Attachment: Testcase

Run test.html from archive. Load it over http and firefox with fuzzPriv extensions. Testcase has some flakiness, looks like some timing factor is involved with vtt file load.

>==22711==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160001fd678 at pc 0x7f33ab37c6dd bp 0x7fff4f7478c0 sp 0x7fff4f7478b8
>READ of size 8 at 0x6160001fd678 thread T0
>    #0 0x7f33ab37c6dc in get objdir-ff-asan/content/media/../../dist/include/nsAutoPtr.h:1039
>    #1 0x7f33ab37c6dc in operator mozilla::dom::TextTrackManager * objdir-ff-asan/content/media/../../dist/include/nsAutoPtr.h:1052
>    #2 0x7f33ab37c6dc in AddCue objdir-ff-asan/content/media/../../dist/include/mozilla/dom/HTMLMediaElement.h:538
>    #3 0x7f33ab37c6dc in mozilla::dom::TextTrack::AddCue(mozilla::dom::TextTrackCue&) content/media/TextTrack.cpp:115
>    #4 0x7f33ab39d67d in mozilla::dom::WebVTTListener::OnCue(JS::Handle<JS::Value>, JSContext*) content/media/WebVTTListener.cpp:169
>    #5 0x7f33a77e9921 in NS_InvokeByIndex xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:162
>    #6 0x7f33aa24f1d7 in Invoke js/xpconnect/src/XPCWrappedNative.cpp:2407
>    #7 0x7f33aa24f1d7 in CallMethodHelper js/xpconnect/src/XPCWrappedNative.cpp:1748
>    #8 0x7f33aa24f1d7 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp:1715
>    #9 0x7f33aa25523e in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1282
>    #10 0x7f33aeab6ab1 in CallJSNative js/src/jscntxtinlines.h:239
>    #11 0x7f33aeab6ab1 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:469
>    #12 0x7f33aeab80ae in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp:532
>    #13 0x7f33ae897244 in js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jsproxy.cpp:465
>    #14 0x7f33ae9cdf86 in js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jswrapper.cpp:465
>    #15 0x7f33ae8b9a65 in js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jsproxy.cpp:2637
>    #16 0x7f33ae8bf5f4 in js::proxy_Call(JSContext*, unsigned int, JS::Value*) js/src/jsproxy.cpp:3040
>    #17 0x7f33aeab6ab1 in CallJSNative js/src/jscntxtinlines.h:239
>    #18 0x7f33aeab6ab1 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:469
>    #19 0x7f33aeaa95da in Interpret(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:2614
>    #20 0x7f33aea8db39 in js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:423
>    #21 0x7f33aeab6fff in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:495
>    #22 0x7f33aeab80ae in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp:532
>    #23 0x7f33ae897244 in js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jsproxy.cpp:465
>    #24 0x7f33ae9cdf86 in js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jswrapper.cpp:465
>    #25 0x7f33ae8b9a65 in js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jsproxy.cpp:2637
>    #26 0x7f33ae8bf5f4 in js::proxy_Call(JSContext*, unsigned int, JS::Value*) js/src/jsproxy.cpp:3040
>    #27 0x7f33aeab6ab1 in CallJSNative js/src/jscntxtinlines.h:239
>    #28 0x7f33aeab6ab1 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:469
>    #29 0x7f33aeab80ae in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp:532
>    #30 0x7f33ae2cc585 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) js/src/jit/BaselineIC.cpp:8235
>
>0x6160001fd678 is located 504 bytes inside of 528-byte region [0x6160001fd480,0x6160001fd690)
>freed by thread T0 here:
>    #0 0x473b81 in __interceptor_free _asan_rtl_
>    #1 0x7f33a76eb73b in SnowWhiteKiller::~SnowWhiteKiller() xpcom/base/nsCycleCollector.cpp:2352
>    #2 0x7f33a76eb339 in nsCycleCollector::FreeSnowWhite(bool) xpcom/base/nsCycleCollector.cpp:2516
>    #3 0x7f33a76f1115 in nsCycleCollector::BeginCollection(ccType, nsICycleCollectorListener*) xpcom/base/nsCycleCollector.cpp:3392
>    #4 0x7f33a76f07f6 in nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*) xpcom/base/nsCycleCollector.cpp:3254
>    #5 0x7f33a76f43a3 in nsCycleCollector_collect(nsICycleCollectorListener*) xpcom/base/nsCycleCollector.cpp:3807
>    #6 0x7f33aa50ee96 in nsJSContext::CycleCollectNow(nsICycleCollectorListener*, int) dom/base/nsJSEnvironment.cpp:1949
>    #7 0x7f33aa50e590 in nsJSEnvironmentObserver::Observe(nsISupports*, char const*, char16_t const*) dom/base/nsJSEnvironment.cpp:277
>    #8 0x7f33a773664c in NotifyObservers xpcom/ds/nsObserverList.cpp:96
>    #9 0x7f33a773664c in nsObserverService::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverService.cpp:302
>    #10 0x7f33a77e9921 in NS_InvokeByIndex xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:162
>    #11 0x7f33aa24f1d7 in Invoke js/xpconnect/src/XPCWrappedNative.cpp:2407
>    #12 0x7f33aa24f1d7 in CallMethodHelper js/xpconnect/src/XPCWrappedNative.cpp:1748
>    #13 0x7f33aa24f1d7 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp:1715
>    #14 0x7f33aa25523e in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1282
>    #15 0x7f33aeab6ab1 in CallJSNative js/src/jscntxtinlines.h:239
>    #16 0x7f33aeab6ab1 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:469
>    #17 0x7f33aeaa95da in Interpret(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:2614
>    #18 0x7f33aea8db39 in js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:423
>    #19 0x7f33aeab6fff in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:495
>    #20 0x7f33ae76f167 in js::CallOrConstructBoundFunction(JSContext*, unsigned int, JS::Value*) js/src/jsfun.cpp:1282
>    #21 0x7f33aeab6ab1 in CallJSNative js/src/jscntxtinlines.h:239
>    #22 0x7f33aeab6ab1 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:469
>    #23 0x7f33aeab80ae in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp:532
>    #24 0x7f33ae897244 in js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jsproxy.cpp:465
>    #25 0x7f33ae9cdf86 in js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jswrapper.cpp:465
>    #26 0x7f33ae8b9a65 in js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/jsproxy.cpp:2637
>    #27 0x7f33ae8bf5f4 in js::proxy_Call(JSContext*, unsigned int, JS::Value*) js/src/jsproxy.cpp:3040
>    #28 0x7f33aeab6ab1 in CallJSNative js/src/jscntxtinlines.h:239
>    #29 0x7f33aeab6ab1 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) js/src/vm/Interpreter.cpp:469
>    #30 0x7f33aeaa95da in Interpret(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:2614
>    #31 0x7f33aea8db39 in js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:423
>    #32 0x7f33aeab99eb in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) js/src/vm/Interpreter.cpp:631
>    #33 0x7f33aeab9f8e in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) js/src/vm/Interpreter.cpp:667
>    #34 0x7f33ae71bc86 in JS::Evaluate(JSContext*, JS::Handle<JSObject*>, JS::ReadOnlyCompileOptions const&, char16_t const*, unsigned long, JS::Value*) js/src/jsapi.cpp:4779
>    #35 0x7f33aa5e0a1a in nsJSUtils::EvaluateString(JSContext*, nsAString_internal const&, JS::Handle<JSObject*>, JS::CompileOptions&, nsJSUtils::EvaluateOptions&, JS::Value*, void**) dom/base/nsJSUtils.cpp:223
>
>previously allocated by thread T0 here:
>    #0 0x473d81 in malloc _asan_rtl_
>    #1 0x7f33b1eb2a7d in moz_xmalloc memory/mozalloc/mozalloc.cpp:52
>    #2 0x7f33ab216ce6 in operator new objdir-ff-asan/content/html/content/src/../../../../dist/include/mozilla/mozalloc.h:201
>    #3 0x7f33ab216ce6 in NS_NewHTMLVideoElement(already_AddRefed<nsINodeInfo>&&, mozilla::dom::FromParser) content/html/content/src/HTMLVideoElement.cpp:37
>    #4 0x7f33ab2998f7 in CreateHTMLElement content/html/document/src/nsHTMLContentSink.cpp:303
>    #5 0x7f33ab2998f7 in NS_NewHTMLElement(mozilla::dom::Element**, already_AddRefed<nsINodeInfo>&&, mozilla::dom::FromParser) content/html/document/src/nsHTMLContentSink.cpp:284
>    #6 0x7f33aaf1ba60 in NS_NewElement(mozilla::dom::Element**, already_AddRefed<nsINodeInfo>&&, mozilla::dom::FromParser) content/base/src/nsNameSpaceManager.cpp:146
>    #7 0x7f33aa3f2dc0 in nsHtml5TreeOperation::CreateElement(int, nsIAtom*, nsHtml5HtmlAttributes*, mozilla::dom::FromParser, nsHtml5DocumentBuilder*) parser/html/nsHtml5TreeOperation.cpp:359
>    #8 0x7f33aa3ffadf in nsHtml5TreeOperation::Perform(nsHtml5TreeOpExecutor*, nsIContent**) parser/html/nsHtml5TreeOperation.cpp:685
>    #9 0x7f33aa3fac19 in nsHtml5TreeOpExecutor::RunFlushLoop() parser/html/nsHtml5TreeOpExecutor.cpp:439
>    #10 0x7f33aa40824b in nsHtml5ExecutorFlusher::Run() parser/html/nsHtml5StreamParser.cpp:128
>    #11 0x7f33a77d64e0 in nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:694
>    #12 0x7f33a76a1d5a in NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:263
>    #13 0x7f33a7f99159 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:95
>    #14 0x7f33a7f42130 in RunInternal ipc/chromium/src/base/message_loop.cc:226
>    #15 0x7f33a7f42130 in RunHandler ipc/chromium/src/base/message_loop.cc:219
>    #16 0x7f33a7f42130 in MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:193
>    #17 0x7f33aa0af447 in nsBaseAppShell::Run() widget/xpwidgets/nsBaseAppShell.cpp:164
>    #18 0x7f33acec5cb8 in nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp:276
>    #19 0x7f33acd351a3 in XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp:4019
>    #20 0x7f33acd3608d in XREMain::XRE_main(int, char**, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp:4088
>    #21 0x7f33acd36edd in XRE_main toolkit/xre/nsAppRunner.cpp:4300
>    #22 0x48c6e7 in do_main browser/app/nsBrowserApp.cpp:282
>    #23 0x48c6e7 in main browser/app/nsBrowserApp.cpp:643
>    #24 0x7f33b5d3b76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
>
>SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??
>Shadow bytes around the buggy address:
>  0x0c2c80037a70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>  0x0c2c80037a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>  0x0c2c80037a90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>  0x0c2c80037aa0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>  0x0c2c80037ab0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>=>0x0c2c80037ac0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]
>  0x0c2c80037ad0: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>  0x0c2c80037ae0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>  0x0c2c80037af0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>  0x0c2c80037b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>  0x0c2c80037b10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
>Shadow byte legend (one shadow byte represents 8 application bytes):
>  Addressable:           00
>  Partially addressable: 01 02 03 04 05 06 07
>  Heap left redzone:       fa
>  Heap right redzone:      fb
>  Freed heap region:       fd
>  Stack left redzone:      f1
>  Stack mid redzone:       f2
>  Stack right redzone:     f3
>  Stack partial redzone:   f4
>  Stack after return:      f5
>  Stack use after scope:   f8
>  Global redzone:          f9
>  Global init order:       f6
>  Poisoned by user:        f7
>  Contiguous container OOB:fc
>  ASan internal:           fe
>==22711==ABORTING
>
>

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/TextTrackManager.h?rev=f653d96cd70b#91

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

(I can't reproduce this on linux)

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

But based on code a minimal testcase should be rather simple to do.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Attachment: more reliable crash

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible fix

Doing still some testing, and going through code to see there are no other
similar cases - or that this would cause leaks.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

https://tbpl.mozilla.org/?tree=Try&rev=86d0ab30c0f4

Comment 7

[Rick Eyre (:reyre)]

Comment on attachment 8398512 [details] [diff] [review]
possible fix

Review of attachment 8398512 [details] [diff] [review]:
-----------------------------------------------------------------

I'm a bit unclear how this would solve the problem since the crash report is saying the smart pointer for TextTrackManager is the one messing up and not the HTMLMediaElement weakptr on the TextTrackManager. Is there some interaction between the two with the GC/CC?

I was always a bit unsure on the decision to make that a weakptr.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Rick Eyre (:reyre) from comment #7)
> I'm a bit unclear how this would solve the problem since the crash report is
> saying the smart pointer for TextTrackManager is the one messing up and not
> the HTMLMediaElement weakptr on the TextTrackManager. Is there some
> interaction between the two with the GC/CC?
How does the crash report say that?

> I was always a bit unsure on the decision to make that a weakptr.
weakptrs are fine, it is raw pointers which aren't.

Comment 9

[Rick Eyre (:reyre)]

(In reply to Olli Pettay [:smaug] from comment #8)
> (In reply to Rick Eyre (:reyre) from comment #7)
> > I'm a bit unclear how this would solve the problem since the crash report is
> > saying the smart pointer for TextTrackManager is the one messing up and not
> > the HTMLMediaElement weakptr on the TextTrackManager. Is there some
> > interaction between the two with the GC/CC?
> How does the crash report say that?

>    #0 0x7f33ab37c6dc in get objdir-ff-asan/content/media/../../dist/include/nsAutoPtr.h:1039
>    #1 0x7f33ab37c6dc in operator mozilla::dom::TextTrackManager * objdir-ff-asan/content/media/../../dist/include/nsAutoPtr.h:1052
>    #2 0x7f33ab37c6dc in AddCue objdir-ff-asan/content/media/../../dist/include/mozilla/dom/HTMLMediaElement.h:538

Line 538 of the MediaElement is a null check:

https://github.com/mozilla/gecko-dev/blob/master/content/html/content/public/HTMLMediaElement.h#L538

So it accesses the smart pointer trying to determine if its raw pointer is null, and it crashes in the get() in the AutoPtr code:

https://github.com/mozilla/gecko-dev/blob/master/xpcom/base/nsAutoPtr.h#L1052

> > I was always a bit unsure on the decision to make that a weakptr.
> weakptrs are fine, it is raw pointers which aren't.

Ah, yes, sorry. Got mixed up.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Rick Eyre (:reyre) from comment #9)
> >    #0 0x7f33ab37c6dc in get objdir-ff-asan/content/media/../../dist/include/nsAutoPtr.h:1039
> >    #1 0x7f33ab37c6dc in operator mozilla::dom::TextTrackManager * objdir-ff-asan/content/media/../../dist/include/nsAutoPtr.h:1052
> >    #2 0x7f33ab37c6dc in AddCue objdir-ff-asan/content/media/../../dist/include/mozilla/dom/HTMLMediaElement.h:538
> 
> Line 538 of the MediaElement is a null check:
> 
> https://github.com/mozilla/gecko-dev/blob/master/content/html/content/public/
> HTMLMediaElement.h#L538
> 
> So it accesses the smart pointer trying to determine if its raw pointer is
> null, and it crashes in the get() in the AutoPtr code:
As far as I see, that is because we end up doing alreadyDeletedMediaElement->mTextTrackManager

The other parts of the report say we create a video element, and delete it later, and then crash

Comment 11

[Rick Eyre (:reyre)]

(In reply to Olli Pettay [:smaug] from comment #10)

> As far as I see, that is because we end up doing
> alreadyDeletedMediaElement->mTextTrackManager

Okay. Thanks for clarifying.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8398512 [details] [diff] [review]
possible fix

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Rather easily. Use of a raw pointer is a clear hint what kind of thing is going wrong.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Commit message could be "Consistently make cycle collector to deal with TextTrackManager's member variables"
So that doesn't point to the issue, but again, this kind of change where the original code has a raw pointer is a strong hint.

Which older supported branches are affected by this flaw?
FF30

If not all supported branches, which bug introduced the flaw?
bug 865407

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
The patch applies to FF30 branch too

How likely is this patch to cause regressions; how much testing does it need?
not likely to cause regressions.

Comment 13

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8398512 [details] [diff] [review]
possible fix

sec-approval+ for trunk. Approved for Aurora too.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0623b2fe08c8

Are we sure this doesn't affect Fx29 as well? The bulk of bug 865407 landed in January (see comment 93).

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

I don't know now what all from bug 865407 landed and when and where.
The bug is marked with "mozilla30", but apparently some of it landed earlier.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Even better, the code in question landed back in October, which implies that this goes back to Fx27. Here it is on b2g28 for example.
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/9d7ed37acfe6

Comment 17

[Rick Eyre (:reyre)]

Ryan is right, I think. The patch that introduced the issue is the 'part 1' patch in bug 865407 and that was landed a while before the rest of the parts so that it wouldn't block other work being done. Here it is in FF29 https://github.com/mozilla/gecko-dev/blob/beta/content/html/content/src/TextTrackManager.h#L82

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0623b2fe08c8

Please nominate this for uplift to Aurora/Beta ASAP. This will land on b2g28 w/ auto-approval once approved for the other branches.

Comment 19

[Al Billings [:abillings - ex-MoCo]]

It is already approved for Aurora. Does the same patch apply to Beta?

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8398512 [details] [diff] [review]
possible fix

Seems to apply with some fuzz.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a7a88d8d692c
https://hg.mozilla.org/releases/mozilla-beta/rev/215560a04513
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/f4c0e9b17eca

Comment 22

[Bogdan Maris, Desktop Test Engineering]

I was able to reproduce the initial issue on Nightly ASAN from 2014-03-27, verified as fixed on latest Nightly, latest Aurora and Firefox 29 beta ASAN builds.