Last Comment Bug 767765 - (CVE-2012-4218) Heap-use-after-free BuildTextRunsScanner::BreakSink::SetBreaks
(CVE-2012-4218)
: Heap-use-after-free BuildTextRunsScanner::BreakSink::SetBreaks
Status: RESOLVED FIXED
[asan][fixed by bug 793233][adv-track...
: crash, sec-critical, testcase
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: x86_64 All
: -- critical (vote)
: mozilla19
Assigned To: Simon Montagu :smontagu
: Matt Wobensmith [:mwobensmith][:matt:]
Mentors:
Depends on: 793233
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-23 22:35 PDT by Abhishek Arya
Modified: 2014-07-22 13:04 PDT (History)
14 users (show)
abillings: sec‑bounty+
mats: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
wontfix
+
fixed
+
fixed
+
fixed
unaffected


Attachments
Testcase (14.67 KB, text/html)
2012-06-23 22:35 PDT, Abhishek Arya
no flags Details

Description Abhishek Arya 2012-06-23 22:35:29 PDT
Created attachment 636135 [details]
Testcase

Reproduces on trunk reliably when run from command line. The testcase is ugly, but seems to be dependent on text runs.
20120623201000
http://hg.mozilla.org/mozilla-central/rev/cb2904476d14

=================================================================
==29398== ERROR: AddressSanitizer heap-use-after-free on address 0x7fd3dc188480 at pc 0x7fd40e3c1930 bp 0x7fffbbf91e10 sp 0x7fffbbf91e08
READ of size 8 at 0x7fd3dc188480 thread T0
    #0 0x7fd40e3c1930 in BuildTextRunsScanner::BreakSink::SetBreaks(unsigned int, unsigned int, unsigned char*) layout/generic/nsTextFrameThebes.cpp:855
    #1 0x7fd40f6b79bc in nsLineBreaker::FlushCurrentWord() content/base/src/nsLineBreaker.cpp:123
    #2 0x7fd40f6c293a in nsLineBreaker::AppendText(nsIAtom*, unsigned char const*, unsigned int, unsigned int, nsILineBreakSink*) content/base/src/nsLineBreaker.cpp:352
    #3 0x7fd40e2f188b in BuildTextRunsScanner::SetupBreakSinksForTextRun(gfxTextRun*, void const*, unsigned int) layout/generic/nsTextFrameThebes.cpp:2216
    #4 0x7fd40e2dc353 in BuildTextRunsScanner::SetupLineBreakerContext(gfxTextRun*) layout/generic/nsTextFrameThebes.cpp:2127
    #5 0x7fd40e2d934f in BuildTextRunsScanner::FlushFrames(bool, bool) layout/generic/nsTextFrameThebes.cpp:1337
    #6 0x7fd40e2fcad8 in BuildTextRuns(gfxContext*, nsTextFrame*, nsIFrame*, nsLineList_iterator const*, nsTextFrame::TextRunType) layout/generic/nsTextFrameThebes.cpp:1285
    #7 0x7fd40e2f8754 in nsTextFrame::EnsureTextRun(nsTextFrame::TextRunType, gfxContext*, nsIFrame*, nsLineList_iterator const*, unsigned int*) layout/generic/nsTextFrameThebes.cpp:2371
    #8 0x7fd40e37cd6d in nsTextFrame::ReflowText(nsLineLayout&, int, nsRenderingContext*, bool, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsTextFrameThebes.cpp:7388
    #9 0x7fd40e1904e8 in nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) layout/generic/nsLineLayout.cpp:836
    #10 0x7fd40e160ebd in nsInlineFrame::ReflowInlineFrame(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned int&) layout/generic/nsInlineFrame.cpp:680
    #11 0x7fd40e15d5ed in nsInlineFrame::ReflowFrames(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsInlineFrame.cpp:543
    #12 0x7fd40e15a8fa in nsInlineFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsInlineFrame.cpp:397
    #13 0x7fd40e19016f in nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) layout/generic/nsLineLayout.cpp:824
    #14 0x7fd40e160ebd in nsInlineFrame::ReflowInlineFrame(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned int&) layout/generic/nsInlineFrame.cpp:680
    #15 0x7fd40e15d5ed in nsInlineFrame::ReflowFrames(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsInlineFrame.cpp:543
    #16 0x7fd40e15a8fa in nsInlineFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsInlineFrame.cpp:397
    #17 0x7fd40e19016f in nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) layout/generic/nsLineLayout.cpp:824
    #18 0x7fd40de4b52f in nsBlockFrame::ReflowInlineFrame(nsBlockReflowState&, nsLineLayout&, nsLineList_iterator, nsIFrame*, LineReflowStatus*) layout/generic/nsBlockFrame.cpp:3834
    #19 0x7fd40de44f8a in nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState&, nsLineLayout&, nsLineList_iterator, nsFlowAreaRect&, int&, nsFloatManager::SavedState*, bool*, LineReflowStatus*, bool) layout/generic/nsBlockFrame.cpp:3630
    #20 0x7fd40de37a07 in nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&, nsLineList_iterator, bool*) layout/generic/nsBlockFrame.cpp:3482
    #21 0x7fd40de263bc in nsBlockFrame::ReflowLine(nsBlockReflowState&, nsLineList_iterator, bool*) layout/generic/nsBlockFrame.cpp:2570
    #22 0x7fd40de0b821 in nsBlockFrame::ReflowDirtyLines(nsBlockReflowState&) layout/generic/nsBlockFrame.cpp:2020
    #23 0x7fd40ddff2bf in nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsBlockFrame.cpp:1069
    #24 0x7fd40deeed97 in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) layout/generic/nsContainerFrame.cpp:906
    #25 0x7fd40e0bf237 in nsCanvasFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsCanvasFrame.cpp:429
    #26 0x7fd40deeed97 in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) layout/generic/nsContainerFrame.cpp:906
    #27 0x7fd40e038b7e in nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState*, bool, bool, nsHTMLReflowMetrics*, bool) layout/generic/nsGfxScrollFrame.cpp:517
    #28 0x7fd40e03e42a in nsHTMLScrollFrame::ReflowContents(ScrollReflowState*, nsHTMLReflowMetrics const&) layout/generic/nsGfxScrollFrame.cpp:617
    #29 0x7fd40e04274f in nsHTMLScrollFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsGfxScrollFrame.cpp:858
    #30 0x7fd40deeed97 in nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) layout/generic/nsContainerFrame.cpp:906
    #31 0x7fd40e416ff1 in ViewportFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsViewportFrame.cpp:200
    #32 0x7fd40db70356 in PresShell::DoReflow(nsIFrame*, bool) layout/base/nsPresShell.cpp:7382
    #33 0x7fd40db9dded in PresShell::ProcessReflowCommands(bool) layout/base/nsPresShell.cpp:7523
    #34 0x7fd40db9c4fd in PresShell::FlushPendingNotifications(mozFlushType) layout/base/nsPresShell.cpp:3852
    #35 0x7fd40dc3f45b in nsRefreshDriver::Notify(nsITimer*) layout/base/nsRefreshDriver.cpp:396
    #36 0x7fd41884a086 in nsTimerImpl::Fire() xpcom/threads/nsTimerImpl.cpp:477
    #37 0x7fd41884bbfc in nsTimerEvent::Run() xpcom/threads/nsTimerImpl.cpp:558
    #38 0x7fd41880e2b3 in nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:625
    #39 0x7fd41849e55d in NS_ProcessNextEvent_P(nsIThread*, bool) objdir-ff-asan-sym/xpcom/build/nsThreadUtils.cpp:217
    #40 0x7fd4175fbff6 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:82
    #41 0x7fd418ac088a in MessageLoop::RunInternal() ipc/chromium/src/base/message_loop.cc:209
    #42 0x7fd418ac06d3 in MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:202
    #43 0x7fd418ac05b8 in MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:176
    #44 0x7fd416b3991e in nsBaseAppShell::Run() widget/xpwidgets/nsBaseAppShell.cpp:165
    #45 0x7fd415783518 in nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp:256
    #46 0x7fd40c1756d7 in XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp:3786
    #47 0x7fd40c17c092 in XREMain::XRE_main(int, char**, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp:3863
    #48 0x7fd40c17f54b in XRE_main toolkit/xre/nsAppRunner.cpp:3939
    #49 0x40a91f in do_main(int, char**) browser/app/nsBrowserApp.cpp:160
    #50 0x40834d in main browser/app/nsBrowserApp.cpp:330
    #51 0x7fd4269c1c4d in ?? ??:0
0x7fd3dc188480 is located 0 bytes inside of 160-byte region [0x7fd3dc188480,0x7fd3dc188520)
freed by thread T0 here:
    #0 0x4a2ed2 in free ??:0
    #1 0x7fd42384f5c3 in moz_free memory/mozalloc/mozalloc.cpp:49
    #2 0x7fd40e406fb3 in gfxTextRun::operator delete(void*) ../../dist/include/gfxFont.h:2335
    #3 0x7fd418e38148 in ~gfxTextRun gfx/thebes/gfxFont.cpp:4338
    #4 0x7fd40e2f778e in nsTextFrame::ClearTextRun(nsTextFrame*, nsTextFrame::TextRunType) layout/generic/nsTextFrameThebes.cpp:4242
    #5 0x7fd40e2f3717 in BuildTextRunsScanner::AssignTextRun(gfxTextRun*, float) layout/generic/nsTextFrameThebes.cpp:2343
    #6 0x7fd40e2e34b8 in BuildTextRunsScanner::BuildTextRunForFrames(void*) layout/generic/nsTextFrameThebes.cpp:2005
    #7 0x7fd40e2d96fd in BuildTextRunsScanner::FlushFrames(bool, bool) layout/generic/nsTextFrameThebes.cpp:1356
    #8 0x7fd40e2e95ba in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1521
    #9 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #10 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #11 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #12 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #13 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #14 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #15 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #16 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #17 0x7fd40e2fc896 in BuildTextRuns(gfxContext*, nsTextFrame*, nsIFrame*, nsLineList_iterator const*, nsTextFrame::TextRunType) layout/generic/nsTextFrameThebes.cpp:1260
    #18 0x7fd40e2f8754 in nsTextFrame::EnsureTextRun(nsTextFrame::TextRunType, gfxContext*, nsIFrame*, nsLineList_iterator const*, unsigned int*) layout/generic/nsTextFrameThebes.cpp:2371
    #19 0x7fd40e37cd6d in nsTextFrame::ReflowText(nsLineLayout&, int, nsRenderingContext*, bool, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsTextFrameThebes.cpp:7388
    #20 0x7fd40e1904e8 in nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) layout/generic/nsLineLayout.cpp:836
    #21 0x7fd40e160ebd in nsInlineFrame::ReflowInlineFrame(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned int&) layout/generic/nsInlineFrame.cpp:680
    #22 0x7fd40e15d5ed in nsInlineFrame::ReflowFrames(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsInlineFrame.cpp:543
    #23 0x7fd40e15a8fa in nsInlineFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsInlineFrame.cpp:397
    #24 0x7fd40e19016f in nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) layout/generic/nsLineLayout.cpp:824
    #25 0x7fd40e160ebd in nsInlineFrame::ReflowInlineFrame(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned int&) layout/generic/nsInlineFrame.cpp:680
    #26 0x7fd40e15d5ed in nsInlineFrame::ReflowFrames(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsInlineFrame.cpp:543
    #27 0x7fd40e15a8fa in nsInlineFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) layout/generic/nsInlineFrame.cpp:397
    #28 0x7fd40e19016f in nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) layout/generic/nsLineLayout.cpp:824
    #29 0x7fd40de4b52f in nsBlockFrame::ReflowInlineFrame(nsBlockReflowState&, nsLineLayout&, nsLineList_iterator, nsIFrame*, LineReflowStatus*) layout/generic/nsBlockFrame.cpp:3834
previously allocated by thread T0 here:
    #0 0x4a2f92 in malloc ??:0
    #1 0x7fd42384fa23 in moz_malloc memory/mozalloc/mozalloc.cpp:64
    #2 0x7fd418e36a66 in gfxTextRun::AllocateStorageForTextRun(unsigned long, unsigned int) gfx/thebes/gfxFont.cpp:4277
    #3 0x7fd418e19dbf in gfxTextRun::Create(gfxTextRunFactory::Parameters const*, unsigned int, gfxFontGroup*, unsigned int) gfx/thebes/gfxFont.cpp:4294
    #4 0x7fd418e1d585 in gfxFontGroup::MakeTextRun(unsigned char const*, unsigned int, gfxTextRunFactory::Parameters const*, unsigned int) gfx/thebes/gfxFont.cpp:3367
    #5 0x7fd40e2efc31 in gfxTextRun* MakeTextRun<unsigned char>(unsigned char const*, unsigned int, gfxFontGroup*, gfxTextRunFactory::Parameters const*, unsigned int) layout/generic/nsTextFrameThebes.cpp:517
    #6 0x7fd40e2e2ea5 in BuildTextRunsScanner::BuildTextRunForFrames(void*) layout/generic/nsTextFrameThebes.cpp:1965
    #7 0x7fd40e2d96fd in BuildTextRunsScanner::FlushFrames(bool, bool) layout/generic/nsTextFrameThebes.cpp:1356
    #8 0x7fd40e2e95ba in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1521
    #9 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #10 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #11 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #12 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #13 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #14 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #15 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #16 0x7fd40e2e9d99 in BuildTextRunsScanner::ScanFrame(nsIFrame*) layout/generic/nsTextFrameThebes.cpp:1559
    #17 0x7fd40e2fc896 in BuildTextRuns(gfxContext*, nsTextFrame*, nsIFrame*, nsLineList_iterator const*, nsTextFrame::TextRunType) layout/generic/nsTextFrameThebes.cpp:1260
    #18 0x7fd40e2f8754 in nsTextFrame::EnsureTextRun(nsTextFrame::TextRunType, gfxContext*, nsIFrame*, nsLineList_iterator const*, unsigned int*) layout/generic/nsTextFrameThebes.cpp:2371
    #19 0x7fd40e37cd6d in nsTextFrame::ReflowText(nsLineLayout&, int, nsRenderingContext*, bool, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsTextFrameThebes.cpp:7388
    #20 0x7fd40e1904e8 in nsLineLayout::ReflowFrame(nsIFrame*, unsigned int&, nsHTMLReflowMetrics*, bool&) layout/generic/nsLineLayout.cpp:836
    #21 0x7fd40e160ebd in nsInlineFrame::ReflowInlineFrame(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsIFrame*, unsigned int&) layout/generic/nsInlineFrame.cpp:680
    #22 0x7fd40e15d5ed in nsInlineFrame::ReflowFrames(nsPresContext*, nsHTMLReflowState const&, nsInlineFrame::InlineReflowState&, nsHTMLReflowMetrics&, unsigned int&) layout/generic/nsInlineFrame.cpp:543
==29398== ABORTING
Stats: 158M malloced (192M for red zones) by 474222 calls
Stats: 42M realloced by 20531 calls
Stats: 114M freed by 238653 calls
Stats: 0M really freed by 0 calls
Stats: 380M (97330 full pages) mmaped in 95 calls
  mmaps   by size class: 8:393192; 9:57337; 10:20475; 11:18423; 12:3072; 13:2048; 14:1536; 15:384; 16:576; 17:128; 18:176; 19:48; 20:16;
  mallocs by size class: 8:383056; 9:48867; 10:17897; 11:17190; 12:2587; 13:1929; 14:1466; 15:348; 16:547; 17:118; 18:163; 19:41; 20:13;
  frees   by size class: 8:167524; 9:37955; 10:14368; 11:13945; 12:1647; 13:991; 14:1252; 15:291; 16:471; 17:103; 18:58; 19:38; 20:10;
  rfrees  by size class:
Stats: malloc large: 335 small slow: 2133
Shadow byte and word:
  0x1ffa7b831090: fd
  0x1ffa7b831090: fd fd fd fd fd fd fd fd
More shadow bytes:
  0x1ffa7b831070: fa fa fa fa fa fa fa fa
  0x1ffa7b831078: fa fa fa fa fa fa fa fa
  0x1ffa7b831080: fa fa fa fa fa fa fa fa
  0x1ffa7b831088: fa fa fa fa fa fa fa fa
=>0x1ffa7b831090: fd fd fd fd fd fd fd fd
  0x1ffa7b831098: fd fd fd fd fd fd fd fd
  0x1ffa7b8310a0: fd fd fd fd fd fd fd fd
  0x1ffa7b8310a8: fd fd fd fd fd fd fd fd
  0x1ffa7b8310b0: fa fa fa fa fa fa fa fa
Comment 1 Daniel Veditz [:dveditz] 2012-06-27 10:51:49 PDT
Jonathon: what's being read here? is it an object with pointers we're going to dereference (very bad) or stuff that's supposed to be text data (less bad)?
Comment 2 Jonathan Kew (:jfkthame) 2012-06-27 12:47:00 PDT
From the stack here, it looks like it's trying to manipulate the glyph records in a textrun that's been deleted; SetPotentialLineBreaks() will want to set line-break flags within some of the CompressedGlyph records. Because this is setting bitfields within those records, it'll first need to read the existing value, but presumably if it weren't getting trapped by ASAN it would then proceed to modify them. As the textrun has (I think) been deleted, that memory might have been reused for some other object, which would therefore get trashed here.

In other words, if I'm reading this right, during reflow we're using a textrun after it's been deleted, which could result in arbitrary corruption of other heap objects (though I'd guess it might be hard to control exactly what gets damaged).
Comment 3 Mats Palmgren (:mats) 2012-07-12 05:18:54 PDT
SetPotentialLineBreaks is a virtual method so this may be exploitable.
Comment 4 Daniel Veditz [:dveditz] 2012-08-02 13:25:02 PDT
qawanted: are Firefox 15 or ESR-10 affected by this bug?
Comment 5 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-09 13:26:48 PDT
(In reply to Daniel Veditz [:dveditz] from comment #4)
> qawanted: are Firefox 15 or ESR-10 affected by this bug?

Do we have Firefox 15 and ESR10 ASAN builds?
Comment 6 David Bolter [:davidb] ***PTO until 29th*** 2012-08-23 14:20:48 PDT
Jonathan any luck figuring out how we might trying to manipulate deleted text runs? (I am so glad I'm not even trying!)
Comment 7 Jonathan Kew (:jfkthame) 2012-08-23 14:42:40 PDT
Bug 769303 dealt with one scenario where we ended up trying to access deleted text runs. It'd be good to confirm whether this still occurs since that patch landed.
Comment 8 David Bolter [:davidb] ***PTO until 29th*** 2012-08-23 14:56:23 PDT
Abhishek, could you try to recreate with trunk? We think this may be fixed as per comment 7.
Comment 9 Abhishek Arya 2012-08-23 15:03:15 PDT
It still reproduces on trunk
20120823080600
http://hg.mozilla.org/mozilla-central/rev/198ca6edd0ae
Comment 10 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-08-28 13:39:34 PDT
Dropping qawanted as I don't believe there is a reasonable way for us to test this for Firefox 15 and ESR.
Comment 12 Daniel Veditz [:dveditz] 2012-09-17 15:12:47 PDT
Running out of time to get a fix into Firefox 16
Comment 13 Alex Keybl [:akeybl] 2012-09-19 17:37:02 PDT
(In reply to Daniel Veditz [:dveditz] from comment #12)
> Running out of time to get a fix into Firefox 16

Specifically, we'd need an uplift prior to Tuesday's go to build to make it into FF16 (or a convincing reason to take it later).
Comment 14 Lukas Blakk [:lsblakk] use ?needinfo 2012-10-03 10:42:51 PDT
We've already gone to build with beta6 so the window on 16 landings has closed. Wontfixing for 16.
Comment 15 Daniel Veditz [:dveditz] 2012-10-15 15:18:03 PDT
I recently read a Planet post saying we'd gotten rid of Thebes -- does that mean this bug is "fixed" on the trunk? That wouldn't help Firefox 17 or 18 users, though (including the upcoming Firefox 17 ESR branch).
Comment 16 Abhishek Arya 2012-10-15 17:15:25 PDT
(In reply to Daniel Veditz [:dveditz] from comment #15)
> I recently read a Planet post saying we'd gotten rid of Thebes -- does that
> mean this bug is "fixed" on the trunk? That wouldn't help Firefox 17 or 18
> users, though (including the upcoming Firefox 17 ESR branch).

Yes, it does not look to reproduce on trunk.
Comment 17 Abhishek Arya 2012-10-15 20:42:10 PDT
Looks like it automatically removed the needinfo? when i commented. Please put it back if needed, i don't know if the question was intended for me.
Comment 18 Jonathan Kew (:jfkthame) 2012-10-16 02:27:11 PDT
(In reply to Daniel Veditz [:dveditz] from comment #15)
> I recently read a Planet post saying we'd gotten rid of Thebes -- does that
> mean this bug is "fixed" on the trunk?

I assume you're referring to Nick C's post? That referred specifically to Thebes *canvas*. Thebes itself is still here, and in particular text layout is still handled by nsTextFrameThebes.

So no, that doesn't imply anything about this bug's status.
Comment 19 Alex Keybl [:akeybl] 2012-10-23 16:05:18 PDT
(In reply to Jonathan Kew (:jfkthame) from comment #18)
> (In reply to Daniel Veditz [:dveditz] from comment #15)
> > I recently read a Planet post saying we'd gotten rid of Thebes -- does that
> > mean this bug is "fixed" on the trunk?
> 
> I assume you're referring to Nick C's post? That referred specifically to
> Thebes *canvas*. Thebes itself is still here, and in particular text layout
> is still handled by nsTextFrameThebes.
> 
> So no, that doesn't imply anything about this bug's status.

What are the next steps here? We're already three weeks into the FF17 beta cycle (and 3 weeks away from release), and I don't see a patch up for review. We need to get moving on this asap.
Comment 20 Jonathan Kew (:jfkthame) 2012-10-25 04:25:20 PDT
I've been unable to reproduce this with asan builds of Nightly (m-c) or Aurora, using either the latest (10/24) or earliest (10/11) builds currently available at https://people.mozilla.com/~choller/firefox/asan/. (See also comment 16.) It would be good if we can determine when it was fixed on trunk, to see if there's a specific patch we should backport. Are there older asan builds available somewhere?

I'm currently attempting to create an asan build of mozilla-beta, to see what the status is there, but my success rate at making custom asan builds hasn't been very good...
Comment 21 Jonathan Kew (:jfkthame) 2012-10-25 05:55:45 PDT
Using an asan build of current mozilla-beta (http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-98a1765f30b1), I still can't reproduce this issue.

Trying to build mozilla-esr10 with asan gave me a bunch of compile errors - it looks like the esr10 tree isn't clang-friendly.

Is it time to resolve as WorksForMe?
Comment 22 Mats Palmgren (:mats) 2012-10-25 06:09:01 PDT
I can still reproduce this in a (few days old) mozilla-central ASAN debug build
on Linux64.
Comment 23 Jonathan Kew (:jfkthame) 2012-10-25 06:28:01 PDT
Hmm, ok - time to try Linux in place of OS X, apparently. Thanks.
Comment 24 Jonathan Kew (:jfkthame) 2012-10-25 11:01:18 PDT
I set up a Linux64 machine and tried choller's builds from 10/12 and 10/25, but both of them loaded the testcase here without hitting the asan error. (They do generate a bunch of assertions about coordinate arithmetic that overflows nscoord_MAX, but that is expected, I think, because the testcase includes some ridiculously-huge dimensions.)
Comment 25 Jonathan Kew (:jfkthame) 2012-10-29 03:53:49 PDT
Mats, would you have time to try and look into this a bit more, as I haven't been able to reproduce it here? (Possibly the behavior depends on some detail of the system configuration?)

From the stacks in comment #0, it looks clear that it's a(nother) case of accessing a textrun after it has been deleted during reflow, but I don't know exactly what the scenario is that's leading to this.
Comment 26 Mats Palmgren (:mats) 2012-10-31 11:19:36 PDT
Hmm, I can't reproduce it either anymore.  I tried my own Linux64 debug asan build
and also decoder's 20121031 debug builds from https://people.mozilla.com/~choller/firefox/asan/ on both Linux64 and OSX.

I do see an assertion though, which might be related to the original crash:
###!!! ASSERTION: Shouldn't be updating the break position with a break that fits after we've already flagged an overrun: '!aFits || !mNeedBackup', file layout/generic/nsLineLayout.h, line 229
Comment 27 Alex Keybl [:akeybl] 2012-10-31 15:30:36 PDT
(In reply to Mats Palmgren [:mats] from comment #26)
> Hmm, I can't reproduce it either anymore.  I tried my own Linux64 debug asan
> build
> and also decoder's 20121031 debug builds from
> https://people.mozilla.com/~choller/firefox/asan/ on both Linux64 and OSX.
> 
> I do see an assertion though, which might be related to the original crash:
> ###!!! ASSERTION: Shouldn't be updating the break position with a break that
> fits after we've already flagged an overrun: '!aFits || !mNeedBackup', file
> layout/generic/nsLineLayout.h, line 229

Given the lack of reproducibility, Matt - can you check when this was fixed?
Comment 28 Al Billings [:abillings] 2012-11-01 10:18:27 PDT
Abhishek, can you reproduce this at all anymore?
Comment 29 Abhishek Arya 2012-11-01 10:31:02 PDT
(In reply to Al Billings [:abillings] from comment #28)
> Abhishek, can you reproduce this at all anymore?

Did a quick recheck, does not reproduce on trunk. Also, had done some time back in c#16.
Comment 30 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-01 10:42:37 PDT
Comment 15 indicates this was fixed by getting rid of Thebes in trunk builds. When did that happen? It would likely help mwobensmith to isolate testing around that time.
Comment 31 Mats Palmgren (:mats) 2012-11-01 10:48:11 PDT
See comment 18.
Comment 32 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-01 10:55:48 PDT
(In reply to Mats Palmgren [:mats] from comment #31)
> See comment 18.

Okay, so it looks like we are stuck blindly trying to find a fix range on mozilla-central ASan between June 23rd and October 15. That's going to be a lot of legwork considering we have to rebuild for each changeset.
Comment 33 Jonathan Kew (:jfkthame) 2012-11-01 11:11:07 PDT
I'm not 100% confident this is in fact "fixed" on trunk, just because we can't currently reproduce it.

Regarding that date range, note that on Oct 25, Mats said (comment 22) that he could "still reproduce this in a (few days old) mozilla-central ASAN debug build", though we don't have an exact date/changeset for that build. So that would imply the bug was still present fairly recently - even if "few days old" actually meant a couple of weeks, that only takes us back to early October.

However, it looks to me like reproducing this has always been rather unpredictable; some people can, some can't. It may depend on details of system configuration (e.g. installed fonts) that in turn affect details of textrun construction, or even something like the precise size of the browser window (as that would affect line-breaking).
Comment 34 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-01 11:21:15 PDT
All of that considered, how critical is this bug to regress? Is it worth QA's time to make this a priority in spite of other Firefox 17 bugs? If not, is regressing this something those who are able to reproduce can do in parallel?
Comment 35 Jonathan Kew (:jfkthame) 2012-11-01 12:08:20 PDT
Regarding how critical it is to chase this down - it'd be good to hear from the security team on that aspect. As of now, I'm not at all confident of making definite progress in the immediate future.

We could try and reproduce with an ASAN build of http://hg.mozilla.org/mozilla-central/rev/198ca6edd0ae (see comment 9); if that's successful, then bisect from there; and if not, it'll be pretty convincing evidence that the bug is not reliably reproducible from a given changeset but depends on some additional factor(s).
Comment 36 Mats Palmgren (:mats) 2012-11-01 15:06:34 PDT
Built from scratch and each tested with a fresh profile:
2012-09-13 6dc63bb388e4  OK
2012-08-31 a6d44513ca62  OK
2012-08-08 3b5094bf47d0  OK
2012-07-11 53860f11100c  OK
2012-06-23 cb2904476d14 (the rev in comment 0)  OK!!!

I think Jonathan is right that the bug depends on external factors, since both
Abhishek and I reproduced the crash at various dates along the way.
Comment 37 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-01 15:11:19 PDT
Thanks Mats, Jonathan, and Abishek. I'm not sure there is anything QA can do to assist with this bug. There's probably other bugs we should focus on instead of this one right now. Please re-add qawanted if there's something we can help with.
Comment 38 Al Billings [:abillings] 2012-11-01 15:35:41 PDT
(In reply to Jonathan Kew (:jfkthame) from comment #35)
> Regarding how critical it is to chase this down - it'd be good to hear from
> the security team on that aspect. As of now, I'm not at all confident of
> making definite progress in the immediate future.

It came to our attention because it is tracking for 17 per flags. If that isn't reasonable, then we should re-evaluate when it is likely to get fixed.
Comment 39 Mats Palmgren (:mats) 2012-11-02 09:48:53 PDT
Forget comment 36, my bad.  I screwed up the mozconfig so it used the system
clang (which on my Ubuntu is 3.0 and does not have support for ASAN, but still
silently ignores -faddress-sanitizer).  After rebuilding the 2012-09-13 rev
using the 3.1 ASAN-capable clang I normally use it's reproducible there.

I'll try to figure out the exact fix range...
Comment 40 Abhishek Arya 2012-11-02 09:51:58 PDT
(In reply to Mats Palmgren [:mats] from comment #39)
> Forget comment 36, my bad.  I screwed up the mozconfig so it used the system
> clang (which on my Ubuntu is 3.0 and does not have support for ASAN, but
> still
> silently ignores -faddress-sanitizer).  After rebuilding the 2012-09-13 rev
> using the 3.1 ASAN-capable clang I normally use it's reproducible there.
> 
> I'll try to figure out the exact fix range...

You can use prebuilt clang binaries from http://commondatastorage.googleapis.com/chromium-browser-clang/index.html?path=Linux_x64/. Also, i remember this testcase was fully reproducible with just one firefox instance.
Comment 41 Mats Palmgren (:mats) 2012-11-02 14:39:13 PDT
Simon's fix for bug 793233 is what fixed it:
https://hg.mozilla.org/mozilla-central/rev/8a9563705dac

I got these assertions before the crash, so that makes sense:
###!!! ASSERTION: Can't find frame in lines!: 'hasNext', file layout/base/nsBidiPresUtils.cpp, line 317
###!!! ABORT: running past end: 'mCurrent != mListLink', file layout/generic/nsLineBox.h, line 681
Comment 42 Mats Palmgren (:mats) 2012-11-06 09:20:04 PST
Bug 793233 has now landed branches too.
Comment 43 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-11-06 14:23:59 PST
RE: in-testsuite?
Is QA verification of this fix required, or will verification be addressed by an in-testsuite testcase?
Comment 44 Daniel Veditz [:dveditz] 2012-11-08 16:35:16 PST
The patch from bug 793233 looks like it is already in ESR-10. Does that mean 793233 is really a backout (partial?) or some other change?
Comment 45 Daniel Veditz [:dveditz] 2012-11-12 15:12:30 PST
If the fix pre-existed on ESR-10 I'm assuming this is a regression of some kind?
Comment 46 Simon Montagu :smontagu 2012-11-12 15:45:03 PST
Bug 793233 was a fix-up for an error in the patch for bug 712600.

(In reply to Daniel Veditz [:dveditz] from comment #44)
> The patch from bug 793233 looks like it is already in ESR-10.

I don't think that's correct.
Comment 47 Mats Palmgren (:mats) 2013-05-14 07:01:13 PDT
Crash test:
https://hg.mozilla.org/integration/mozilla-inbound/rev/93db1ba4ddee
Comment 48 Ryan VanderMeulen [:RyanVM] 2013-05-14 13:30:00 PDT
https://hg.mozilla.org/mozilla-central/rev/93db1ba4ddee

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