Last Comment Bug 812893 - (CVE-2013-0780) Heap-use-after-free in nsOverflowContinuationTracker::Finish, with -moz-columns
(CVE-2013-0780)
: Heap-use-after-free in nsOverflowContinuationTracker::Finish, with -moz-columns
Status: RESOLVED FIXED
[asan][bug 724978 might fix][adv-main...
: crash, csectype-uaf, sec-critical, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla21
Assigned To: Mats Palmgren (:mats)
: Matt Wobensmith [:mwobensmith][:matt:]
: Jet Villegas (:jet)
Mentors:
: 821126 (view as bug list)
Depends on: 724978
Blocks: 821126
  Show dependency treegraph
 
Reported: 2012-11-18 09:15 PST by Abhishek Arya
Modified: 2016-12-01 13:31 PST (History)
14 users (show)
dveditz: sec‑bounty+
mats: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
+
verified
+
verified
+
verified
19+
verified
19+
fixed
fixed


Attachments
Testcase (802 bytes, text/html)
2012-11-18 09:15 PST, Abhishek Arya
no flags Details
bogus frame tree (3.87 KB, text/html)
2013-01-23 08:34 PST, Mats Palmgren (:mats)
no flags Details
fix (4.18 KB, patch)
2013-01-23 09:21 PST, Mats Palmgren (:mats)
roc: review+
bajaj.bhavana: approval‑mozilla‑aurora+
bajaj.bhavana: approval‑mozilla‑beta+
bajaj.bhavana: approval‑mozilla‑esr17+
bajaj.bhavana: approval‑mozilla‑b2g18+
abillings: sec‑approval+
Details | Diff | Splinter Review

Description Abhishek Arya 2012-11-18 09:15:12 PST
Created attachment 682899 [details]
Testcase

Reproduces on trunk.

=================================================================
==3869== ERROR: AddressSanitizer: heap-use-after-free on address 0x7facf171c940 at pc 0x7fad10189afe bp 0x7fff43a32a90 sp 0x7fff43a32a88
READ of size 8 at 0x7facf171c940 thread T0
    #0 0x7fad10189afd in nsFrameList::FirstChild() const src/layout/base/../generic/nsFrameList.h:214
    #1 0x7fad10a06005 in nsOverflowContinuationTracker::Finish(nsIFrame*) src/layout/generic/nsContainerFrame.cpp:1719
    #2 0x7fad109a7a57 in nsBlockReflowContext::ReflowBlock(nsRect const&, bool, nsCollapsingMargin&, int, bool, nsLineBox*, nsHTMLReflowState&, unsigned int&, nsBlockReflowState&) src/layout/generic/nsBlockReflowContext.cpp:306
    #3 0x7fad10949e9d in nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:3097
    #4 0x7fad1093ebe9 in nsBlockFrame::ReflowLine(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:2476
    #5 0x7fad1092a670 in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) src/layout/generic/nsBlockFrame.cpp:2284
    #6 0x7fad10918fe3 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsBlockFrame.cpp:1041
    #7 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #8 0x7fad109e6ad3 in nsColumnSetFrame::ReflowChildren(nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&, nsColumnSetFrame::ReflowConfig const&, bool, nsCollapsingMargin*, nsColumnSetFrame::ColumnBalanceData&) src/layout/generic/nsColumnSetFrame.cpp:649
    #9 0x7fad109eeb11 in nsColumnSetFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsColumnSetFrame.cpp:1032
    #10 0x7fad109a7400 in nsBlockReflowContext::ReflowBlock(nsRect const&, bool, nsCollapsingMargin&, int, bool, nsLineBox*, nsHTMLReflowState&, unsigned int&, nsBlockReflowState&) src/layout/generic/nsBlockReflowContext.cpp:268
    #11 0x7fad10949e9d in nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:3097
    #12 0x7fad1093ebe9 in nsBlockFrame::ReflowLine(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:2476
    #13 0x7fad10925cf7 in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) src/layout/generic/nsBlockFrame.cpp:1996
    #14 0x7fad10918fe3 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsBlockFrame.cpp:1041
    #15 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #16 0x7fad109e6ad3 in nsColumnSetFrame::ReflowChildren(nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&, nsColumnSetFrame::ReflowConfig const&, bool, nsCollapsingMargin*, nsColumnSetFrame::ColumnBalanceData&) src/layout/generic/nsColumnSetFrame.cpp:649
    #17 0x7fad109eeb11 in nsColumnSetFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsColumnSetFrame.cpp:1032
    #18 0x7fad109a7400 in nsBlockReflowContext::ReflowBlock(nsRect const&, bool, nsCollapsingMargin&, int, bool, nsLineBox*, nsHTMLReflowState&, unsigned int&, nsBlockReflowState&) src/layout/generic/nsBlockReflowContext.cpp:268
    #19 0x7fad10949e9d in nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:3097
    #20 0x7fad1093ebe9 in nsBlockFrame::ReflowLine(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:2476
    #21 0x7fad10925cf7 in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) src/layout/generic/nsBlockFrame.cpp:1996
    #22 0x7fad10918fe3 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsBlockFrame.cpp:1041
    #23 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #24 0x7fad109e6ad3 in nsColumnSetFrame::ReflowChildren(nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&, nsColumnSetFrame::ReflowConfig const&, bool, nsCollapsingMargin*, nsColumnSetFrame::ColumnBalanceData&) src/layout/generic/nsColumnSetFrame.cpp:649
    #25 0x7fad109eeb11 in nsColumnSetFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsColumnSetFrame.cpp:1032
    #26 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #27 0x7fad10bd7066 in nsCanvasFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsCanvasFrame.cpp:473
    #28 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #29 0x7fad10b4e948 in nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState*, bool, bool, nsHTMLReflowMetrics*, bool) src/layout/generic/nsGfxScrollFrame.cpp:433
    #30 0x7fad10b534a6 in nsHTMLScrollFrame::ReflowContents(ScrollReflowState*, nsHTMLReflowMetrics const&) src/layout/generic/nsGfxScrollFrame.cpp:533
    #31 0x7fad10b57b40 in nsHTMLScrollFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsGfxScrollFrame.cpp:774
    #32 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #33 0x7fad10f4692a in ViewportFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsViewportFrame.cpp:202
    #34 0x7fad106799bb in PresShell::DoReflow(nsIFrame*, bool) src/layout/base/nsPresShell.cpp:7502
    #35 0x7fad106a906d in PresShell::ProcessReflowCommands(bool) src/layout/base/nsPresShell.cpp:7643
    #36 0x7fad106a7bbe in PresShell::FlushPendingNotifications(mozFlushType) src/layout/base/nsPresShell.cpp:3883
    #37 0x7fad1074e155 in nsRefreshDriver::Notify(nsITimer*) src/layout/base/nsRefreshDriver.cpp:403
    #38 0x7fad1cc44123 in nsTimerImpl::Fire() src/xpcom/threads/nsTimerImpl.cpp:485
    #39 0x7fad1cc454c1 in nsTimerEvent::Run() src/xpcom/threads/nsTimerImpl.cpp:565
    #40 0x7fad1cc081be in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:627
    #41 0x7fad1c87de0f in NS_ProcessNextEvent_P(nsIThread*, bool) src/objdir-ff-asan-sym/xpcom/build/nsThreadUtils.cpp:221
    #42 0x7fad1afe3516 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:82
    #43 0x7fad1cef0cce in MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:215
    #44 0x7fad1cef0b15 in MessageLoop::RunHandler() src/ipc/chromium/src/base/message_loop.cc:208
    #45 0x7fad1cef09fb in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:182
    #46 0x7fad1a3e84d4 in nsBaseAppShell::Run() src/widget/xpwidgets/nsBaseAppShell.cpp:163
    #47 0x7fad18f4de12 in nsAppStartup::Run() src/toolkit/components/startup/nsAppStartup.cpp:290
    #48 0x7fad0e437f24 in XREMain::XRE_mainRun() src/toolkit/xre/nsAppRunner.cpp:3823
    #49 0x7fad0e43dbf9 in XREMain::XRE_main(int, char**, nsXREAppData const*) src/toolkit/xre/nsAppRunner.cpp:3890
    #50 0x7fad0e440970 in XRE_main src/toolkit/xre/nsAppRunner.cpp:4084
    #51 0x40c0c6 in do_main(int, char**) src/browser/app/nsBrowserApp.cpp:174
    #52 0x409900 in main src/browser/app/nsBrowserApp.cpp:279
    #53 0x7fad2e64e76c in ?? ??:0
0x7facf171c940 is located 0 bytes inside of 16-byte region [0x7facf171c940,0x7facf171c950)
freed by thread T0 here:
    #0 0x4c3750 in __interceptor_free ??:?
    #1 0x7fad2c1dc405 in moz_free src/memory/mozalloc/mozalloc.cpp:48
    #2 0x7fad10a0da58 in operator delete(void*) src/../../dist/include/mozilla/mozalloc.h:224
    #3 0x7fad10a0cef3 in nsContainerFrame::StealFrame(nsPresContext*, nsIFrame*, bool) src/layout/generic/nsContainerFrame.cpp:1212
    #4 0x7fad10984dac in nsBlockFrame::StealFrame(nsPresContext*, nsIFrame*, bool) src/layout/generic/nsBlockFrame.cpp:5538
    #5 0x7fad10a0f51c in nsContainerFrame::DeleteNextInFlowChild(nsPresContext*, nsIFrame*, bool) src/layout/generic/nsContainerFrame.cpp:1359
    #6 0x7fad10986c30 in nsBlockFrame::DeleteNextInFlowChild(nsPresContext*, nsIFrame*, bool) src/layout/generic/nsBlockFrame.cpp:5625
    #7 0x7fad109a7ba2 in nsBlockReflowContext::ReflowBlock(nsRect const&, bool, nsCollapsingMargin&, int, bool, nsLineBox*, nsHTMLReflowState&, unsigned int&, nsBlockReflowState&) src/layout/generic/nsBlockReflowContext.cpp:307
    #8 0x7fad10949e9d in nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:3097
    #9 0x7fad1093ebe9 in nsBlockFrame::ReflowLine(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:2476
    #10 0x7fad10925cf7 in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) src/layout/generic/nsBlockFrame.cpp:1996
    #11 0x7fad10918fe3 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsBlockFrame.cpp:1041
    #12 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #13 0x7fad109e6ad3 in nsColumnSetFrame::ReflowChildren(nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&, nsColumnSetFrame::ReflowConfig const&, bool, nsCollapsingMargin*, nsColumnSetFrame::ColumnBalanceData&) src/layout/generic/nsColumnSetFrame.cpp:649
    #14 0x7fad109eeb11 in nsColumnSetFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsColumnSetFrame.cpp:1032
previously allocated by thread T0 here:
    #0 0x4c3810 in malloc ??:?
    #1 0x7fad2c1dc541 in moz_xmalloc src/memory/mozalloc/mozalloc.cpp:54
    #2 0x7fad10a0b40f in operator new(unsigned long) src/../../dist/include/mozilla/mozalloc.h:200
    #3 0x7fad1094dbbe in nsBlockFrame::ReflowBlockFrame(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:3266
    #4 0x7fad1093ebe9 in nsBlockFrame::ReflowLine(nsBlockReflowState&, nsLineList_iterator, bool*) src/layout/generic/nsBlockFrame.cpp:2476
    #5 0x7fad1092a670 in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) src/layout/generic/nsBlockFrame.cpp:2284
    #6 0x7fad10918fe3 in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) src/layout/generic/nsBlockFrame.cpp:1041
    #7 0x7fad10a0566c in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) src/layout/generic/nsContainerFrame.cpp:952
    #8 0x7fad109e6ad3 in nsColumnSetFrame::ReflowChildren(nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&, nsColumnSetFrame::ReflowConfig const&, bool, nsCollapsingMargin*, nsColumnSetFrame::ColumnBalanceData&) src/layout/generic/nsColumnSetFrame.cpp:649
Shadow byte and word:
  0x1ff59e2e3928: fd
  0x1ff59e2e3928: fd fd fd fd fd fd fd fd
More shadow bytes:
  0x1ff59e2e3908: 00 00 00 00 00 fb fb fb
  0x1ff59e2e3910: fa fa fa fa fa fa fa fa
  0x1ff59e2e3918: fd fd fd fd fd fd fd fd
  0x1ff59e2e3920: fa fa fa fa fa fa fa fa
=>0x1ff59e2e3928: fd fd fd fd fd fd fd fd
  0x1ff59e2e3930: fa fa fa fa fa fa fa fa
  0x1ff59e2e3938: 00 00 00 00 00 00 00 00
  0x1ff59e2e3940: fa fa fa fa fa fa fa fa
  0x1ff59e2e3948: fd fd fd fd fd fd fd fd
Stats: 252M malloced (231M for red zones) by 340183 calls
Stats: 46M realloced by 17894 calls
Stats: 221M freed by 224349 calls
Stats: 186M really freed by 177540 calls
Stats: 235M (60247 full pages) mmaped in 447 calls
  mmaps   by size class: 7:102375; 8:45034; 9:13299; 10:5110; 11:8670; 12:1280; 13:960; 14:544; 15:224; 16:784; 17:460; 18:36; 19:35; 20:21;
  mallocs by size class: 7:196151; 8:83366; 9:22929; 10:9146; 11:19278; 12:2496; 13:1908; 14:1548; 15:413; 16:1467; 17:1349; 18:70; 19:40; 20:22;
  frees   by size class: 7:122554; 8:54394; 9:16555; 10:5987; 11:17304; 12:1710; 13:1495; 14:1365; 15:281; 16:1256; 17:1334; 18:57; 19:38; 20:19;
  rfrees  by size class: 7:99289; 8:43459; 9:10392; 10:4360; 11:13903; 12:1343; 13:996; 14:1255; 15:215; 16:939; 17:1297; 18:49; 19:37; 20:6;
Stats: malloc large: 3361 small slow: 4876
==3869== ABORTING
Comment 1 Mats Palmgren (:mats) 2012-11-19 12:05:45 PST
The underlying issue is probably bug 724978.
Other related crash bugs: bug 772320, bug 783228, bug 772306.
Comment 2 David Bolter [:davidb] 2012-11-21 10:16:07 PST
Mats, how bad is this?
Comment 3 Daniel Veditz [:dveditz] 2012-11-28 10:19:35 PST
If this bad pointer is being read in framelist code why aren't we getting a poisoned value instead of a UAF?
Comment 4 Mats Palmgren (:mats) 2012-11-30 12:01:49 PST
I'm pretty sure the underlying problem is bug 724978 comment 1.
(I have no intention of taking that bug.)
Comment 5 Daniel Veditz [:dveditz] 2012-12-06 13:23:27 PST
If the underlying issue is bug 724978 then this may well affect Firefox 17 or even Fx10. We'll have to test since other intervening changes may have masked the problem in the older releases.
Comment 6 David Bolter [:davidb] 2012-12-13 13:09:56 PST
Assigning to Ehsan since he has made some progress on bug 724978.
Comment 7 :Ehsan Akhgari 2012-12-13 14:01:39 PST
Sorry I don't have any idea what's going on here...
Comment 8 David Bolter [:davidb] 2012-12-20 12:13:56 PST
Scott can you own this one for now and let us know if/when bug 724978 might help us?
Comment 9 Scott Johnson (:jwir3) 2012-12-20 12:16:54 PST
(In reply to David Bolter [:davidb] from comment #8)
> Scott can you own this one for now and let us know if/when bug 724978 might
> help us?

Ok... I don't know when bug 724978 will land, though, or even when I'll have a chance to work on it. 

What is the priority of this as compared to bug 724978? If I understand correctly, bug 724978 is not a high priority bug at the moment, but I could be wrong...
Comment 10 David Bolter [:davidb] 2012-12-20 12:44:09 PST
(In reply to Scott Johnson (:jwir3) from comment #9)
> (In reply to David Bolter [:davidb] from comment #8)
> > Scott can you own this one for now and let us know if/when bug 724978 might
> > help us?
> 
> Ok... I don't know when bug 724978 will land, though, or even when I'll have
> a chance to work on it. 
> 
> What is the priority of this as compared to bug 724978? If I understand
> correctly, bug 724978 is not a high priority bug at the moment, but I could
> be wrong...

Unless we discover this is not a sec-critical, this bug is very high priority indeed.
Comment 11 Scott Johnson (:jwir3) 2012-12-20 12:58:25 PST
mats, one thing that I'm not clear on is why you think this would be fixed by 724978... it doesn't seem like there is abspos stuff in this testcase at all. Then again, I'm not sure how -moz-shape-inside is interacting with the columns.
Comment 12 Scott Johnson (:jwir3) 2012-12-20 14:57:33 PST
What are the STR to reproduce this? I don't seem to see it on my trunk builds...


> Shadow byte and word:
>   0x1ff59e2e3928: fd
>   0x1ff59e2e3928: fd fd fd fd fd fd fd fd
> More shadow bytes:
>   0x1ff59e2e3908: 00 00 00 00 00 fb fb fb
>   0x1ff59e2e3910: fa fa fa fa fa fa fa fa
>   0x1ff59e2e3918: fd fd fd fd fd fd fd fd
>   0x1ff59e2e3920: fa fa fa fa fa fa fa fa
> =>0x1ff59e2e3928: fd fd fd fd fd fd fd fd
>   0x1ff59e2e3930: fa fa fa fa fa fa fa fa
>   0x1ff59e2e3938: 00 00 00 00 00 00 00 00
>   0x1ff59e2e3940: fa fa fa fa fa fa fa fa
>   0x1ff59e2e3948: fd fd fd fd fd fd fd fd
> Stats: 252M malloced (231M for red zones) by 340183 calls
> Stats: 46M realloced by 17894 calls
> Stats: 221M freed by 224349 calls
> Stats: 186M really freed by 177540 calls
> Stats: 235M (60247 full pages) mmaped in 447 calls
>    mmaps   by size class: 7:102375; 8:45034; 9:13299; 10:5110; 11:8670; 12:1280; 
> 13:960; 14:544; 15:224; 16:784; 17:460; 18:36; 19:35; 20:21;
>   mallocs by size class: 7:196151; 8:83366; 9:22929; 10:9146; 11:19278; 12:2496; 
> 13:1908; 14:1548; 15:413; 16:1467; 17:1349; 18:70; 19:40; 20:22;
>   frees   by size class: 7:122554; 8:54394; 9:16555; 10:5987; 11:17304; 12:1710; 
> 13:1495; 14:1365; 15:281; 16:1256; 17:1334; 18:57; 19:38; 20:19;
>   rfrees  by size class: 7:99289; 8:43459; 9:10392; 10:4360; 11:13903; 12:1343; 
> 13:996; 14:1255; 15:215; 16:939; 17:1297; 18:49; 19:37; 20:6;
> Stats: malloc large: 3361 small slow: 4876
> ==3869== ABORTING

Is this valgrind output?
Comment 13 Mats Palmgren (:mats) 2012-12-20 16:05:14 PST
(In reply to Scott Johnson (:jwir3) from comment #11)
> mats, one thing that I'm not clear on is why you think this would be fixed
> by 724978...

I don't recall exactly, but these frames in the reported stack dump:
    #1 0x7fad10a06005 in nsOverflowContinuationTracker::Finish(nsIFrame*)
    #9 0x7fad109eeb11 in nsColumnSetFrame::Reflow
seems to indicate it's the problem we discussed in bug 724978 comment 1.

(In reply to Scott Johnson (:jwir3) from comment #12)
> What are the STR to reproduce this? I don't seem to see it on my trunk
> builds...

Load the testcase in an Address Sanitizer (ASan) build.

> Is this valgrind output?

It's ASan output.  See this link for details:
https://developer.mozilla.org/en-US/docs/Building_Firefox_with_Address_Sanitizer
Comment 14 Al Billings [:abillings] 2012-12-27 13:05:39 PST
Any updates on this?
Comment 15 Scott Johnson (:jwir3) 2012-12-28 08:20:23 PST
(In reply to Al Billings [:abillings] from comment #14)
> Any updates on this?

Not yet, sorry. I'm trying to determine if this is a regression from something recent (and thus we can fix it by backing this out), or if it's something that's been around for a while.

Based on my bisecting so far, it seems like the former is likely, but it's slow going.
Comment 16 Alex Keybl [:akeybl] 2013-01-07 17:17:49 PST
(In reply to Scott Johnson (:jwir3) from comment #15)
> (In reply to Al Billings [:abillings] from comment #14)
> > Any updates on this?
> 
> Based on my bisecting so far, it seems like the former is likely, but it's
> slow going.

Matt should be able to help out. Assigning him as the QA contact.
Comment 17 Matt Wobensmith [:mwobensmith][:matt:] 2013-01-08 15:14:10 PST
I'm not able to see a crash. Using m-c ASan builds from 11/16, 11/19 and 1/7 (most current) all three builds exhibit the same behavior. I'm getting 1200+ warnings and asserts when loading this bug file, but no crash. 

WARNING: Overflowed nscoord_MAX in conversion to nscoord width: file ../../dist/include/nsRect.h, line 130
nsBlockReflowContext: ColumnSet(form)(4)@0x1212f10f8 metrics=2147482818,1152!
###!!! ASSERTION: Doing nscoord addition with values > nscoord_MAX: 'a < nscoord_MAX && b < nscoord_MAX', file ../../dist/include/nsCoord.h, line 195
WARNING: nscoord addition capped to nscoord_MAX: '(int64_t)a + (int64_t)b < (int64_t)nscoord_MAX', file ../../dist/include/nsCoord.h, line 201

Our ASan archive only goes back a few weeks. I just happened to have the above older builds on my local machine.
Comment 18 Mats Palmgren (:mats) 2013-01-09 09:56:08 PST
That's odd.  I can reproduce this in my local m-c ASan debug Linux64 build...
Comment 19 Mats Palmgren (:mats) 2013-01-09 10:03:47 PST
I've been debugging this a bit and I think I know what the problem is --
nsOverflowContinuationTracker::Insert screws up the frame lists when it
moves a frame with continuations to the overflow containers list.

Scott, are you working on this or should I take it?
Comment 20 Scott Johnson (:jwir3) 2013-01-09 11:34:06 PST
(In reply to Mats Palmgren [:mats] from comment #19)
> I've been debugging this a bit and I think I know what the problem is --
> nsOverflowContinuationTracker::Insert screws up the frame lists when it
> moves a frame with continuations to the overflow containers list.
> 
> Scott, are you working on this or should I take it?

Nope, feel free to take it. I would like to speak with you about this, when you have a chance, though, just so I can get an idea of how you went about debugging this issue. (For learning purposes).
Comment 21 Mats Palmgren (:mats) 2013-01-23 08:34:40 PST
Created attachment 705378 [details]
bogus frame tree
Comment 23 Mats Palmgren (:mats) 2013-01-23 09:23:12 PST
A few notes:
nsOverflowContinuationTracker::Insert is kind of weird in that it
expects a non-NS_FRAME_IS_OVERFLOW_CONTAINER frame to not be on any
frame list and thus no StealFrame is required in that case.

Also, it has the problem that it recurse on OVERFLOW_CONTAINER
continuations and thus can cause stack overflow.

nsOverflowContinuationTracker can point to either the
ExcessOverflowContinuations list or the OverflowContinuations on the
next-in-flow (stored in mParent).  This seems overly complicated.
I think it would be simpler to always add the frames to the
ExcessOverflowContinuations list and then the next-in-flow can
drain that at the start of its ReflowOverflowContainerChildren.
Comment 24 Robert O'Callahan (:roc) (email my personal email if necessary) 2013-01-23 13:50:31 PST
(In reply to Mats Palmgren [:mats] from comment #23)
> A few notes:
> nsOverflowContinuationTracker::Insert is kind of weird in that it
> expects a non-NS_FRAME_IS_OVERFLOW_CONTAINER frame to not be on any
> frame list and thus no StealFrame is required in that case.
> 
> Also, it has the problem that it recurse on OVERFLOW_CONTAINER
> continuations and thus can cause stack overflow.
> 
> nsOverflowContinuationTracker can point to either the
> ExcessOverflowContinuations list or the OverflowContinuations on the
> next-in-flow (stored in mParent).  This seems overly complicated.
> I think it would be simpler to always add the frames to the
> ExcessOverflowContinuations list and then the next-in-flow can
> drain that at the start of its ReflowOverflowContainerChildren.

Can you work on these issues? I think it's super-important to simplify this code as much as possible.
Comment 25 Mats Palmgren (:mats) 2013-01-23 17:55:11 PST
I filed bug 834097 and bug 834096.  I'll try to find some time inbetween other work.
Comment 26 Mats Palmgren (:mats) 2013-01-23 18:22:25 PST
Comment on attachment 705397 [details] [diff] [review]
fix

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
I don't think the patch gives any clues at all.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
No.

Which older supported branches are affected by this flaw?
I'm guessing all, but I haven't checked.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
I think the same patch would apply, this code doesn't change much.

How likely is this patch to cause regressions; how much testing does it need?
This code is complicated so I would say moderate risk.
Comment 27 Al Billings [:abillings] 2013-01-24 13:57:31 PST
I'm giving sec-approval but please check to see how far back we're affected.
Comment 29 Alex Keybl [:akeybl] 2013-01-24 16:10:21 PST
Please nominate for uplift to Aurora/Beta no later than Monday. Please also prepare patches for ESR17 or B2G (if the phone is affected).
Comment 30 Ryan VanderMeulen [:RyanVM] 2013-01-26 17:05:04 PST
https://hg.mozilla.org/mozilla-central/rev/ed2ed42808ca
Comment 31 Mats Palmgren (:mats) 2013-01-27 10:03:01 PST
Comment on attachment 705397 [details] [diff] [review]
fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): none
User impact if declined: sec-critical crash
Testing completed (on m-c, etc.): on m-c since 2013-01-26
Risk to taking this patch (and alternatives if risky): medium risk, no alt.
String or UUID changes made by this patch: none
Comment 32 bhavana bajaj [:bajaj] 2013-01-28 13:53:59 PST
Comment on attachment 705397 [details] [diff] [review]
fix

Approving on branches as this is sec-high and baked well on m-c.Considering the risk is moderate but since we do not have any alt, please involve Matt Wobensmith for any additional testing/verfication that may be helpful here.

Please land no later than tomorrow morning for this to make it into 19.0b4 to get good beta testing.
Comment 33 Daniel Veditz [:dveditz] 2013-01-28 15:07:13 PST
*** Bug 821126 has been marked as a duplicate of this bug. ***
Comment 36 Matt Wobensmith [:mwobensmith][:matt:] 2013-01-31 09:18:02 PST
As mentioned above in comment 17, I've not been able to see a crash. However, I can see that the assert is gone in the latest builds. The warnings are still present.

Verified on build 2013-01-31, m-c
Verified on build 2013-01-31, Aurora
Verified on beta 19b4
Verified on build 2013-01-30, 17.0.2esr
Comment 37 Lukas Blakk [:lsblakk] use ?needinfo 2013-02-13 10:58:45 PST
Batch edit: Bugs fixed on b2g18 after 1/25 merge to v1.0 branch are fixed on v1.0.1 branch.
Comment 38 Mats Palmgren (:mats) 2014-07-18 10:05:36 PDT
Landed the crashtest:
https://hg.mozilla.org/integration/mozilla-inbound/rev/88df072cf29b
Comment 39 Wes Kocher (:KWierso) 2014-07-18 17:57:06 PDT
https://hg.mozilla.org/mozilla-central/rev/88df072cf29b

Note You need to log in before you can comment on or make changes to this bug.