Closed Bug 1338772 Opened 7 years ago Closed 7 years ago

heap-use-after-free in mozilla::PresShell::FlushPendingNotifications

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox-esr45 --- unaffected
firefox51 --- unaffected
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 --- fixed

People

(Reporter: nils, Assigned: dholbert)

References

Details

(Keywords: csectype-uaf, regression, sec-moderate)

Attachments

(3 files, 1 obsolete file)

The following testcase crashes the latest ASAN build of Firefox:

<script>
function start () {
        o0=document.createElement('iframe');
        o0.src="data:text/html,<html><body>";
        o0.addEventListener('load', fun1,false);
        document.body.appendChild(o0);
}
function fun1() {
        o4=o0.contentDocument;
        o8=o4.getElementsByTagName('*')[2];
        o30=document.createElement('iframe');
        o8.appendChild(o30);
        document.documentElement.setAttribute('style',"");
        o30.contentWindow.onresize=fun2;
        o30.height='-11px';
        try{document.documentElement.insertAdjacentHTML('beforend',"");}catch(e){}
}
function fun2() {
location.reload()
}
</script>
<body onload="start()"></body>


=================================================================
==3870==ERROR: AddressSanitizer: heap-use-after-free on address 0x61700010b6d2 at pc 0x7f5af8eac6de bp 0x7ffc881e7890 sp 0x7ffc881e7888
WRITE of size 1 at 0x61700010b6d2 thread T0 (Web Content)
    #0 0x7f5af8eac6dd in ~AutoRestore /home/worker/workspace/build/src/obj-firefox/dist/include/mozilla/AutoRestore.h:45:15
    #1 0x7f5af8eac6dd in mozilla::PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) /home/worker/workspace/build/src/layout/base/PresShell.cpp:4265
    #2 0x7f5af9207db0 in mozilla::ScrollFrameHelper::AsyncScrollPortEvent::Run() /home/worker/workspace/build/src/layout/generic/nsGfxScrollFrame.cpp:4750:5
    #3 0x7f5af903dbd9 in nsRootPresContext::FlushWillPaintObservers() /home/worker/workspace/build/src/layout/base/nsPresContext.cpp:3283:5
    #4 0x7f5af9045b94 in nsRootPresContext::RunWillPaintObservers::Run() /home/worker/workspace/build/src/layout/base/nsPresContext.h:1592:9
    #5 0x7f5af25d6e8b in nsThread::ProcessNextEvent(bool, bool*) /home/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1261:7
    #6 0x7f5af25d37e0 in NS_ProcessNextEvent(nsIThread*, bool) /home/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:389:10
    #7 0x7f5af33e222f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/worker/workspace/build/src/ipc/glue/MessagePump.cpp:96:21
    #8 0x7f5af33544b8 in RunInternal /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:238:3
    #9 0x7f5af33544b8 in RunHandler /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:231
    #10 0x7f5af33544b8 in MessageLoop::Run() /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:211
    #11 0x7f5af876b98f in nsBaseAppShell::Run() /home/worker/workspace/build/src/widget/nsBaseAppShell.cpp:156:3
    #12 0x7f5afbf6f467 in XRE_RunAppShell() /home/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:852:12
    #13 0x7f5af33544b8 in RunInternal /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:238:3
    #14 0x7f5af33544b8 in RunHandler /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:231
    #15 0x7f5af33544b8 in MessageLoop::Run() /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:211
    #16 0x7f5afbf6ef4c in XRE_InitChildProcess(int, char**, XREChildData const*) /home/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:684:7
    #17 0x4e00c6 in content_process_main /home/worker/workspace/build/src/browser/app/../../ipc/contentproc/plugin-container.cpp:64:19
    #18 0x4e00c6 in main /home/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:284
    #19 0x7f5b0d96f82f in __libc_start_main /build/glibc-t3gR2i/glibc-2.23/csu/../csu/libc-start.c:291
    #20 0x41c2e8 in _start (/home/nils/fuzzer3/firefox/firefox+0x41c2e8)

0x61700010b6d2 is located 338 bytes inside of 752-byte region [0x61700010b580,0x61700010b870)
freed by thread T0 (Web Content) here:
    #0 0x4b2a3b in __interceptor_free /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:38:3
    #1 0x7f5af8e88ad4 in mozilla::PresShell::Release() /home/worker/workspace/build/src/layout/base/PresShell.cpp:892:1
    #2 0x7f5af8eac506 in ~nsCOMPtr_base /home/worker/workspace/build/src/obj-firefox/dist/include/nsCOMPtr.h:294:7
    #3 0x7f5af8eac506 in mozilla::PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) /home/worker/workspace/build/src/layout/base/PresShell.cpp:4265
    #4 0x7f5af9207db0 in mozilla::ScrollFrameHelper::AsyncScrollPortEvent::Run() /home/worker/workspace/build/src/layout/generic/nsGfxScrollFrame.cpp:4750:5
    #5 0x7f5af903dbd9 in nsRootPresContext::FlushWillPaintObservers() /home/worker/workspace/build/src/layout/base/nsPresContext.cpp:3283:5
    #6 0x7f5af9045b94 in nsRootPresContext::RunWillPaintObservers::Run() /home/worker/workspace/build/src/layout/base/nsPresContext.h:1592:9
    #7 0x7f5af25d6e8b in nsThread::ProcessNextEvent(bool, bool*) /home/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1261:7
    #8 0x7f5af25d37e0 in NS_ProcessNextEvent(nsIThread*, bool) /home/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:389:10
    #9 0x7f5af33e222f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/worker/workspace/build/src/ipc/glue/MessagePump.cpp:96:21
    #10 0x7f5af33544b8 in RunInternal /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:238:3
    #11 0x7f5af33544b8 in RunHandler /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:231
    #12 0x7f5af33544b8 in MessageLoop::Run() /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:211
    #13 0x7f5af876b98f in nsBaseAppShell::Run() /home/worker/workspace/build/src/widget/nsBaseAppShell.cpp:156:3
    #14 0x7f5afbf6f467 in XRE_RunAppShell() /home/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:852:12
    #15 0x7f5af33544b8 in RunInternal /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:238:3
    #16 0x7f5af33544b8 in RunHandler /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:231
    #17 0x7f5af33544b8 in MessageLoop::Run() /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:211
    #18 0x7f5afbf6ef4c in XRE_InitChildProcess(int, char**, XREChildData const*) /home/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:684:7
    #19 0x4e00c6 in content_process_main /home/worker/workspace/build/src/browser/app/../../ipc/contentproc/plugin-container.cpp:64:19
    #20 0x4e00c6 in main /home/worker/workspace/build/src/browser/app/nsBrowserApp.cpp:284
    #21 0x7f5b0d96f82f in __libc_start_main /build/glibc-t3gR2i/glibc-2.23/csu/../csu/libc-start.c:291

previously allocated by thread T0 (Web Content) here:
    #0 0x4b2d5b in malloc /builds/slave/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52:3
    #1 0x4e10cd in moz_xmalloc /home/worker/workspace/build/src/memory/mozalloc/mozalloc.cpp:83:17
    #2 0x7f5af4fa332d in operator new /home/worker/workspace/build/src/obj-firefox/dist/include/mozilla/mozalloc.h:194:12
    #3 0x7f5af4fa332d in nsDocument::CreateShell(nsPresContext*, nsViewManager*, mozilla::StyleSetHandle) /home/worker/workspace/build/src/dom/base/nsDocument.cpp:3797
    #4 0x7f5af8f99f7c in nsDocumentViewer::InitPresentationStuff(bool) /home/worker/workspace/build/src/layout/base/nsDocumentViewer.cpp:680:16
    #5 0x7f5af8faae6a in nsDocumentViewer::Show() /home/worker/workspace/build/src/layout/base/nsDocumentViewer.cpp:2130:12
    #6 0x7f5afb44f7d9 in SetVisibility /home/worker/workspace/build/src/docshell/base/nsDocShell.cpp:6483:5
    #7 0x7f5afb44f7d9 in non-virtual thunk to nsDocShell::SetVisibility(bool) /home/worker/workspace/build/src/docshell/base/nsDocShell.cpp:6473
    #8 0x7f5af5050cca in nsFrameLoader::Show(int, int, int, int, nsSubDocumentFrame*) /home/worker/workspace/build/src/dom/base/nsFrameLoader.cpp:1143:3
    #9 0x7f5af9309085 in nsSubDocumentFrame::ShowViewer() /home/worker/workspace/build/src/layout/generic/nsSubDocumentFrame.cpp:191:9
    #10 0x7f5af938773b in AsyncFrameInit::Run() /home/worker/workspace/build/src/layout/generic/nsSubDocumentFrame.cpp:91:7
    #11 0x7f5af4bded0e in nsContentUtils::RemoveScriptBlocker() /home/worker/workspace/build/src/dom/base/nsContentUtils.cpp:5261:5
    #12 0x7f5af8eabe1e in ~nsAutoScriptBlocker /home/worker/workspace/build/src/obj-firefox/dist/include/nsContentUtils.h:2947:5
    #13 0x7f5af8eabe1e in mozilla::PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) /home/worker/workspace/build/src/layout/base/PresShell.cpp:4197
    #14 0x7f5af8e3c5c9 in nsRefreshDriver::Tick(long, mozilla::TimeStamp) /home/worker/workspace/build/src/layout/base/nsRefreshDriver.cpp:1819:11
    #15 0x7f5af8e4a855 in mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) /home/worker/workspace/build/src/layout/base/nsRefreshDriver.cpp:295:7
    #16 0x7f5af8e4a524 in mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) /home/worker/workspace/build/src/layout/base/nsRefreshDriver.cpp:317:5
    #17 0x7f5af8e4c564 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::TimeStamp) /home/worker/workspace/build/src/layout/base/nsRefreshDriver.cpp:506:9
    #18 0x7f5af96c1d64 in mozilla::layout::VsyncChild::RecvNotify(mozilla::TimeStamp const&) /home/worker/workspace/build/src/layout/ipc/VsyncChild.cpp:64:5
    #19 0x7f5af3809cd8 in mozilla::layout::PVsyncChild::OnMessageReceived(IPC::Message const&) /home/worker/workspace/build/src/obj-firefox/ipc/ipdl/PVsyncChild.cpp:160:20
    #20 0x7f5af3493373 in mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&) /home/worker/workspace/build/src/obj-firefox/ipc/ipdl/PBackgroundChild.cpp:1425:16
    #21 0x7f5af33da320 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) /home/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1795:14
    #22 0x7f5af33d685c in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) /home/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1730:17
    #23 0x7f5af33d8e94 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) /home/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1603:5
    #24 0x7f5af33d94de in mozilla::ipc::MessageChannel::MessageTask::Run() /home/worker/workspace/build/src/ipc/glue/MessageChannel.cpp:1636:5
    #25 0x7f5af25d6e8b in nsThread::ProcessNextEvent(bool, bool*) /home/worker/workspace/build/src/xpcom/threads/nsThread.cpp:1261:7
    #26 0x7f5af25d37e0 in NS_ProcessNextEvent(nsIThread*, bool) /home/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp:389:10
    #27 0x7f5af33e222f in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/worker/workspace/build/src/ipc/glue/MessagePump.cpp:96:21
    #28 0x7f5af33544b8 in RunInternal /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:238:3
    #29 0x7f5af33544b8 in RunHandler /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:231
    #30 0x7f5af33544b8 in MessageLoop::Run() /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:211
    #31 0x7f5af876b98f in nsBaseAppShell::Run() /home/worker/workspace/build/src/widget/nsBaseAppShell.cpp:156:3
    #32 0x7f5afbf6f467 in XRE_RunAppShell() /home/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:852:12
    #33 0x7f5af33544b8 in RunInternal /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:238:3
    #34 0x7f5af33544b8 in RunHandler /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:231
    #35 0x7f5af33544b8 in MessageLoop::Run() /home/worker/workspace/build/src/ipc/chromium/src/base/message_loop.cc:211
    #36 0x7f5afbf6ef4c in XRE_InitChildProcess(int, char**, XREChildData const*) /home/worker/workspace/build/src/toolkit/xre/nsEmbedFunctions.cpp:684:7

SUMMARY: AddressSanitizer: heap-use-after-free /home/worker/workspace/build/src/obj-firefox/dist/include/mozilla/AutoRestore.h:45:15 in ~AutoRestore
Shadow bytes around the buggy address:
  0x0c2e80019680: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e80019690: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e800196a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e800196b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e800196c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2e800196d0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd
  0x0c2e800196e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e800196f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c2e80019700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa
  0x0c2e80019710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c2e80019720: 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
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3870==ABORTING
Group: core-security → dom-core-security
Keywords: csectype-uaf
Can you look at this Cameron? It may be a regression from bug 1334735.

The free has this stack:
    #1 0x7f5af8e88ad4 in mozilla::PresShell::Release() /home/worker/workspace/build/src/layout/base/PresShell.cpp:892:1
    #2 0x7f5af8eac506 in ~nsCOMPtr_base /home/worker/workspace/build/src/obj-firefox/dist/include/nsCOMPtr.h:294:7
    #3 0x7f5af8eac506 in mozilla::PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) /home/worker/workspace/build/src/layout/base/PresShell.cpp:4265

The use has this stack:
    #0 0x7f5af8eac6dd in ~AutoRestore /home/worker/workspace/build/src/obj-firefox/dist/include/mozilla/AutoRestore.h:45:15
    #1 0x7f5af8eac6dd in mozilla::PresShell::FlushPendingNotifications(mozilla::ChangesToFlush) /home/worker/workspace/build/src/layout/base/PresShell.cpp:4265

PresShell::FlushPendingNotifications has this line in it:
  AutoRestore<bool> guard(mInFlush);
then later it has this:
  nsCOMPtr<nsIPresShell> kungFuDeathGrip;

So it looks like we're exiting PresShell::FlushPendingNotifications, and we first destroy the death grip (because it was declared later), which ends up destroying |this|. Then later we hit the AutoRestore, and try to touch |this|.
Flags: needinfo?(cam)
Component: DOM → Layout
See Also: → 1339566
Group: dom-core-security → layout-core-security
Ugh, I should have caught this.  The AutoRestore definitely needs to move down below the kungFuDeathGrip....
(In reply to Andrew McCreight [:mccr8] from comment #1)
> Can you look at this Cameron?

(I'll jump in and take this, since I discussed this briefly with mccr8 IRL and it seems easy enough to fix.)

> It may be a regression from bug 1334735.

Yeah, that's where we added this AutoRestore. Seems likely to be a regression from that.

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #2)
> Ugh, I should have caught this.  The AutoRestore definitely needs to move
> down below the kungFuDeathGrip....

Might be less invasive to just declare the deathgrip earlier, right? (We can keep its *assignment* intact, so it'll still only be acquired when needed.  But if we declare it earlier, then (if it's the only thing keeping us alive) it'll keep us alive long enough for the AutoRestore to safely do its bool-restoration.)

I'm less sure which functionality might care about the AutoRestore (& its corresponding "mInFlush = true" assignment).
Flags: needinfo?(cam)
Assignee: nobody → dholbert
Comment on attachment 8837304 [details] [diff] [review]
fix v1: shift kungFuDeathGrip decl earlier

I'm fairly sure the strong ref to the viewmanager needs to go out of scope _after_ the one to the presshell.  Or at least there are (very old) comments to that effect in ResizeReflowIgnoreOverride...  I can't recall now why that is, though.
Attachment #8837304 - Flags: review-
So to be clear, I think moving the grips is _more_ invasive here, which is why I was suggesting the other thing, as long as we check that nothing in between depends on the value of that boolean.
Mm, good catch - I hadn't noticed the RefPtr to the viewmanager. OK, I'll look into the strategy you suggested then.
I've audited the other uses of AutoRestore in the tree and filed a few bugs, plus a bug for possibly adding a static analysis to catch this.

In terms of figuring out how exploitable this might be, the only other non-POD stack variable I see being declared between the AutoRestore and the COMPtr is RefPtr<nsViewManager> viewManager, so in theory the dtor for that could run. I'm not sure if that does any allocation, but it does seem reasonably involved.
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #6)
> as long as we check that nothing in
> between depends on the value of that boolean.

Due diligence on this:
 - the boolean is "mInFlush".
 - It's only read in one place -- nsIPresShell::NeedFlush() (where it's one of many conditions that make us return true).
 - That function is only called in one place -- in nsDocument::FlushPendingNotifications().

So we only need to care about entry points to nsDocument::FlushPendingNotifications().  That function has an explicit call in the PresShell.cpp function that we're modifying here, and that's clearly the section that this AutoRestore is meant to wrap.

So this seems fine.  But further, here's a list of the function calls between the old location and the new location:
   * PresShell::IsSafeToFlush()
     -- This calls some other accessors internally, but it seems like a pretty safe bet that this shouldn't itself call nsDocument::FlushPendingNotifications() internally.

   * nsIDocument::GetScriptHandlingObject
     -- This seems like a fancy getter, basically (with a helper impl in nsDocument::GetScriptHandlingObjectInternal which is also a fancy getter). I don't immediately see any way it could trigger a nsDocument::FlushPendingNotifications() call internally.

   * nsContentUtils::IsSafeToRunScript()
     -- This is just a getter (it immediately returns true or false depending on the value of a counter)

So bz's suggestion should be good. I'm tentatively going to move the AutoRestore *inside* the "isSafeToFlush" if-check, since that seems to the the section that it's meant to guard anyway.
Attachment #8837363 - Attachment description: fix v2: Scope mInFlush tweak a bit closer to the actual flushing → fix v2: Scope mInFlush tweak a bit closer to the actual flushing (just moving code)
BTW, I verified that I can reproduce the ASAN abort locally, and both fixes that I've attached are successful at avoiding it.
Thanks for finding and fixing this.
Comment on attachment 8837363 [details] [diff] [review]
fix v2: Scope mInFlush tweak a bit closer to the actual flushing (just moving code)

r=me
Attachment #8837363 - Flags: review?(bzbarsky) → review+
(In reply to Andrew McCreight [:mccr8] from comment #8)
> I've audited the other uses of AutoRestore in the tree and filed a few bugs,
> plus a bug for possibly adding a static analysis to catch this.

Are any of the bugs scary enough that we should hold off on this patch & fix/uplift them all at once?

Otherwise, I think we're good to go here (no sec-approval needed, since this is Nightly only, as a regression from bug 1334735).
Flags: needinfo?(continuation)
(In reply to Daniel Holbert [:dholbert] from comment #14)
> Are any of the bugs scary enough that we should hold off on this patch &
> fix/uplift them all at once?

Nah, I think this is the scariest one, and it doesn't seem that bad.
Blocks: 1334735
Flags: needinfo?(continuation)
Here's a reduced testcase which reliably triggers this in ASAN builds. (It's derived from comment 0.)

I'll land this as a crashtest ~tomorrow, after the patch has made it to Nightly users.
Flags: needinfo?(dholbert)
Attachment #8837722 - Attachment description: reduced testcase 1 → reduced testcase 1 (crashes unpatched ASAN builds)
Flags: needinfo?(dholbert)
Flags: needinfo?(dholbert)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Try run with the crashtest, based on a before-the-fix changeset:
 https://treeherder.mozilla.org/#/jobs?repo=try&revision=47e706ee15142a8ec2ce784b9d02961858309f73
(Crashtest 1338772-1.html expected to fail, in the ASAN runner at least)

Try run with the crashtest, based on an after-the-fix changeset:
 https://treeherder.mozilla.org/#/jobs?repo=try&revision=e816b138989680d919a13563c9d799d8a49bbe48
(Crashtest 1338772-1.html expected to pass)
Try runs matched my expectations. Landed crashtest:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a11b78b38ed4e65848ca06d0ff45d261c2182c05
Flags: needinfo?(dholbert)
Flags: in-testsuite?
Flags: in-testsuite+
Flags: sec-bounty?
Depends on: 1340441
Flags: sec-bounty? → sec-bounty+
Group: layout-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.