Closed Bug 767765 (CVE-2012-4218) Opened 12 years ago Closed 12 years ago

Heap-use-after-free BuildTextRunsScanner::BreakSink::SetBreaks

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla19
Tracking Flags:
Tracking Status
firefox16 + wontfix
firefox17 + fixed
firefox18 + fixed
firefox19 + fixed
firefox-esr10 --- unaffected

People

(Reporter: inferno, Assigned: smontagu)

References

Details

(4 keywords, Whiteboard: [asan][fixed by bug 793233][adv-track-main17+][qa?])

Crash Data

Attachments

(1 file)

Testcase
14.67 KB, text/html
Details
Attached file 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
OS: Windows 7 → All
Whiteboard: [asan]
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
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)?
Assignee: nobody → jfkthame
Summary: Heap-use-after-free BuildTextRunsScanner::BreakSink::SetBreaks → Heap-use-after-free (read) BuildTextRunsScanner::BreakSink::SetBreaks
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).
SetPotentialLineBreaks is a virtual method so this may be exploitable.
Severity: normal → critical
Keywords: sec-high → crash, sec-critical
qawanted: are Firefox 15 or ESR-10 affected by this bug?
Keywords: qawanted
(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?
Jonathan any luck figuring out how we might trying to manipulate deleted text runs? (I am so glad I'm not even trying!)
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.
Abhishek, could you try to recreate with trunk? We think this may be fixed as per comment 7.
Whiteboard: [asan] → [asan][Possibly fixed by Bug 769303]
It still reproduces on trunk
20120823080600
http://hg.mozilla.org/mozilla-central/rev/198ca6edd0ae
Dropping qawanted as I don't believe there is a reasonable way for us to test this for Firefox 15 and ESR.
Keywords: qawanted
Whiteboard: [asan][Possibly fixed by Bug 769303] → [asan]
Running out of time to get a fix into Firefox 16
(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).
We've already gone to build with beta6 so the window on 16 landings has closed. Wontfixing for 16.
status-firefox16: affected → wontfix
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).
Flags: needinfo?
(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.
Flags: needinfo?
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.
(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.
Crash Signature: [@ BuildTextRunsScanner::BreakSink::SetBreaks(unsigned int, unsigned int, unsigned char*) ] [@ @0x0 | BuildTextRunsScanner::BreakSink::SetBreaks(unsigned int, unsigned int, unsigned char*) ]
Whiteboard: [asan] → [asan] fix-range-wanted
(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.
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...
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?
I can still reproduce this in a (few days old) mozilla-central ASAN debug build
on Linux64.
Hmm, ok - time to try Linux in place of OS X, apparently. Thanks.
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.)
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.
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
(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?
Keywords: qawanted
QA Contact: mwobensmith
Abhishek, can you reproduce this at all anymore?
(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 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.
(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.
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).
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?
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).
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.
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.
Keywords: qawanted
(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.
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...
(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.
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
Depends on: 793233
Whiteboard: [asan] fix-range-wanted → [asan]
Bug 793233 has now landed branches too.
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox17: affected → fixed
status-firefox18: affected → fixed
status-firefox19: affected → fixed
Flags: in-testsuite?
Keywords: regressionwindow-wanted
Resolution: --- → FIXED
Whiteboard: [asan] → [asan][fixed by bug 793233]
Target Milestone: --- → mozilla19
Whiteboard: [asan][fixed by bug 793233] → [asan][fixed by bug 793233][adv-track-main17+]
RE: in-testsuite?
Is QA verification of this fix required, or will verification be addressed by an in-testsuite testcase?
Whiteboard: [asan][fixed by bug 793233][adv-track-main17+] → [asan][fixed by bug 793233][adv-track-main17+][qa?]
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?
Assignee: jfkthame → smontagu
status-firefox-esr10: --- → unaffected
Flags: sec-bounty+
If the fix pre-existed on ESR-10 I'm assuming this is a regression of some kind?
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.
Alias: CVE-2012-4218
Summary: Heap-use-after-free (read) BuildTextRunsScanner::BreakSink::SetBreaks → Heap-use-after-free BuildTextRunsScanner::BreakSink::SetBreaks
Group: core-security
Crash test:
https://hg.mozilla.org/integration/mozilla-inbound/rev/93db1ba4ddee
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: