348514 - (CVE-2006-4253) Crash at http://lcamtuf.coredump.cx/ffoxdie.html (NOT due to too-much-recursion) [@ nsTextFrame::PrepareUnicodeText] [@ nsAutoIndexBuffer::~nsAutoIndexBuffer] (CVE-2006-4253)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[u88484]

Found a link that says "Flaw in Firefox 1.5.0.6: remote code execution", clicked on link and firefox (trunk) crashed and produced TB22044224Y. 

Stack Signature	 SelectorMatches b51e851e
Product ID	FirefoxTrunk
Build ID	2006081204
Trigger Time	2006-08-13 05:00:00.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (00264494)
URL visited	
User Comments	
Since Last Crash	3224 sec
Total Uptime	3224 sec
Trigger Reason	Stack overflow
Source File, Line No.	c:\builds\tinderbox\fx-trunk-cairo\winnt_5.2_depend\mozilla\layout\style\nscssruleprocessor.cpp, line 1333
Stack Trace 	
SelectorMatches   nsGenericElement::GetID   0x8d50006a

Found this link in the same thread: http://www.securityfocus.com/bid/19488/discuss

and tH on irc said to post this link along with this: http://lists.grok.org.uk/pipermail/full-disclosure/2006-August/048711.html

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase

Testcase currently at http://lcamtuf.coredump.cx/ffoxdie.html

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #0)
> Trigger Reason  Stack overflow

That's (a) pretty much incompatible with remote code execution and (b) a sign that what's on the very top of the stack is irrelevant.  Unfortunately talkback doesn't show anything else useful.

Comment 3

[Jesse Ruderman]

On Mac OS X I see a stack overflow (too-much-recursion crash).

...
45  nsCSSFrameConstructor::ConstructFrameInternal + 1500
46  nsCSSFrameConstructor::ConstructFrame + 252
47  nsCSSFrameConstructor::ProcessInlineChildren + 412
48  nsCSSFrameConstructor::ConstructInline + 172
49  nsCSSFrameConstructor::ConstructFrameByDisplayType + 1468
50  nsCSSFrameConstructor::ConstructFrameInternal + 1500
...

The Windows Talkback report also says this is a stack overflow.

From looking at part of the testcase I'd guess this is a dup of bug 323394.

I don't know what to make of Michal Zalewski's claim that there is a concurrency issue allowing JavaScript to interrupt the XML parser and cause a memory safety violation.  It's hard to tell with the stack overflow crash getting in the way ;)

Comment 4

[jpl24]

Ugh...I ran the test case on a debug executable with MSVC attached and got a BSOD. Not helpful.

Comment 5

[Thomas K. (:tom)]

Camino Version 2006061318 (1.0.2)
TB22051950Y

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I can reproduce this (using Firefox 1.5.0.6) on OS X and Windows, but
not on Linux (SuSE Linux 9.2, fully updated).

Comment 7

[Steven Michaud [:smichaud] (Retired)]

I don't crash on Linux using today's trunk nightly, either
(2006-08-13-04-trunk).

Comment 8

[Michal Zalewski]

(In reply to comment #3)
> The Windows Talkback report also says this is a stack overflow.

My bad - on a sufficiently fast link and test machine, the version provided on the website may reach a separate stack overflow condition before it gets to the actual problem. In other words, rendering http://lcamtuf.coredump.cx/ffoxdie.xml  alone will crash the browser due to a stack overflow, given enough time.

http://lcamtuf.coredump.cx/ffoxdie2.html should be a version that works better with systems that crash with ffoxdie.html (in this example, ffoxdie2.xml is not considerably shorter). The caveat is that the attack window for Javascript-triggered reload action is shorter.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase 2

current contents of http://lcamtuf.coredump.cx/ffoxdie2.html

Comment 10

[Steven Michaud [:smichaud] (Retired)]

With http://lcamtuf.coredump.cx/ffoxdie2.html (and this bug's
"testcase 2" attachment 233509 [details]) I only crash on Windows ... and my
crash is the same stack overflow that Jesse got on Mac OS X (the
"trigger reason" is also listed as "stack overflow).

TB22060059Y

I have a ~1.3 Mbit ADSL connection.

Comment 11

[timeless]

if you get a bsod, file a bug indicating a crash and i'll walk you through finding which driver is buggy.

Comment 12

[Daniel Veditz [:dveditz]]

Is the frame in ffoxdie2.html supposed to be showing an XML parsing error? (the last x element is incomplete: "<x") I'm not crashing, that's eventually replaced with a "Congratulations" frame, but maybe the testcase is not working properly? 

In the ffoxdie.html case I crash immediately with the stack overflow, before any XML parsing error is shown.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

As far as drivers can tell, there's no exploitable security bug here, so this is a crash case like several others, and not something we'll block release on at this point.

Comment 14

[Michal Zalewski]

(In reply to comment #13)
> As far as drivers can tell, there's no exploitable security bug here

The behavior of the testcases I supplied is admittably quite weird - I can see no particular pattern, but they do cause a call stack overflow on some systems, and a more interesting crash on others.

Here's a slightly different on-reload issue that should give more predictable results: http://lcamtuf.coredump.cx/ffoxdie3.html .

Cheers,
/mz

Comment 15

[Steven Michaud [:smichaud] (Retired)]

> http://lcamtuf.coredump.cx/ffoxdie3.html

With this URL I don't crash anywhere (on Mac OS X, SuSE Linux or
Windows XP Pro, all using Firefox 1.5.0.6), even after repeated
reloads, and even if some of the reloads interrupt previous reloads
(in other words, if I click again on the reload button before the
script has finished running).

It might help, Michal, if you posted one of your own crash logs :-)

Comment 16

[Michal Zalewski]

(In reply to comment #15)
> With this URL I don't crash anywhere (on Mac OS X, SuSE Linux or
> Windows XP Pro, all using Firefox 1.5.0.6)

You seem to be in the minority as far as I'm concerned - I did test it on three separate platforms, and asked a couple folks at random to run a test for me. You might want to try ffoxdie3_max.html, which tests a wider set of timings.

Talkback crash report, as requested: TB22131211Z

Comment 17

[Jesse Ruderman]

Does Firefox trunk crash on ffoxdie3.html / ffoxdie3_max.html?  Or does the trunk only suffer from the stack overflow on the other URLs?

Can you reproduce the crash in a clean profile (with no extensions)?

Do you have Talkback stack traces that show something other than random hex addresses?  Random hex addresses do suggest the presence of a security hole but a stack trace showing *only* random hex addresses doesn't help much in diagnosing the bug.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #16)
> Talkback crash report, as requested: TB22131211Z

That looks like the talkback server doesn't have the symbols for the build you're using.  (The addresses look perfectly good, though.)  Could you try with a newer build?

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

SeaMonkey trunk on Windows crashes too:

http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB22134321K

Comment 20

[Jesse Ruderman]

> SeaMonkey trunk on Windows crashes too: TB22134321K

We don't need more confirmation of the stack overflow crash.  We do need confirmation / a useful stack / a reduced testcase for the other crash.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

> You might want to try ffoxdie3_max.html, which tests a wider set of
> timings.

I get the same results with this as with ffoxdie3.html -- no crashes.
(Once again I tested with Firefox 1.5.0.6.)

This time, in addition to sometimes clicking randomly on the reload
button while the script was running, I also sometimes randomly clicked
on the stop button, or closed the tab and/or the window before the
script had finished.  (I did, of course, also try running the script
to its conclusion and then reloading.)

As I mentioned above, I have a ~1.3 megabit ADSL connection.  And
though my Linux box is pretty fancy, that's not true of either my Mac
or my Windows "box" (which is actually a VMWare session running on top
of my Linux box).

For the record, I have:

1) A Linux box (running SuSE Linux 9.2) built around a Tyan Thunder
   K8W motherboard with two 2GHz AMD Opteron CPUs (64-bit) and 2 gigs
   or RAM.

2) Windows XP Pro running in a VMWare session on the Linux box with
   256 megs of RAM.

3) A dual 1GHz PowerPC G4 Macintosh desktop with 512 megs of RAM, on
   which I can run either Mac OS X 10.4.7 or 10.3.9 (I tested in both).

It may be relevant that I have very plain-vanilla installations of
Firefox on all three of these "machines" -- for example, none of them
have any extensions.

Comment 22

[Michal Zalewski]

(In reply to comment #21)
> I get the same results with this as with ffoxdie3.html -- no crashes.
> (Once again I tested with Firefox 1.5.0.6.)

Of all unique IPs in my access-log with "Firefox" in User-Agent who visited ffoxdie3_i.html subpage (which contains the Javascript-loaded payload, indicative that the test has started), 60% (about a hundred) did not load ffoxdie3_ok.html (the "congratulations" page), suggesting a crash (not the stack overflow that frequently shows up in previous examples due to excessive nesting of XML tags).

This leds me to believe that this is really not that hard to reproduce, and that I'm not a lone bozo.

It really does not seem to be something that can't be reproduced; and I'm testing it with a vanilla installation of 1.5.0.6 on three separate machines, with no extensions installed.

Cheers,
/mz

Comment 23

[Steven Michaud [:smichaud] (Retired)]

I find that Mac OS X's crashreporterd's crash logs are much more
informative than those produced by Talkback.  If you know of anyone
who has crashed on Mac OS X (excluding the stack overflow crashes that
have already been reported here), please encourage them to attach one
or more crashreporterd crash logs here.

They are quite long, so people who want to "post" their crashreporterd
crash logs here should choose "Create a New Attachment", instead of
just pasting the logs into a comment.

With each new crash, crashreporterd appends a new log to an
application-specific file in ~/Library/Logs/CrashReporter.  Firefox
crashes get appended to firefox-bin.crash.log.

Comment 24

[Rob Marshall [tH]]

I couldn't get trunk to break, but ffoxdie3 reliably crashes 1.5.0.6 and today's 2.0 nightly for me. Are TB22158693W and TB22159036X useful?

Comment 25

[Steven Michaud [:smichaud] (Retired)]

> Are TB22158693W and TB22159036X useful?

I think so.  On the face of it, it looks like a window has received a
PAINT message for an object that (at least partially) no longer
exists.  I suspect this could be a concurrency issue ... but I'm not
familiar with that part of the Mozilla.org codebase.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

Talkback crash logs disappear from the server in a week or two, so
here are copies of TB22158693W and TB22159036X:

TB22158693W

Stack Signature  ntdll.dll + 0x3336f (0x77f8336f) 9b9b9a2f
Product ID       Firefox15
Build ID         2006072814
Trigger Time     2006-08-16 10:15:55.0
Platform         Win32
Operating System Windows NT 5.1 build 2600
Module           ntdll.dll + (0003336f)
URL visited
User Comments    bug 348514 /rdmsoft
Since Last Crash 348 sec
Total Uptime     384885 sec
Trigger Reason   Access violation
Source File, Line No.    N/A
Stack Trace
ntdll.dll + 0x3336f (0x77f8336f)
ntdll.dll + 0x8b7b (0x77f58b7b)
msvcrt.dll + 0x1ab2e (0x77c2ab2e)
nsAutoPRUint8Buffer::~nsAutoPRUint8Buffer
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsTextFrame.cpp, line 175]
nsTextFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsTextFrame.cpp, line 1644]
nsContainerFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 283]
nsBlockFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/tables/../generic\nsBlockFrame.h, line 287]
nsBlockFrame::PaintChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6445]
nsHTMLContainerFrame::PaintDecorationsAndChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLContainerFrame.cpp, line 138]
nsBlockFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6272]
nsContainerFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 283]
nsBlockFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/tables/../generic\nsBlockFrame.h, line 287]
nsBlockFrame::PaintChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6445]
nsHTMLContainerFrame::PaintDecorationsAndChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLContainerFrame.cpp, line 138]
nsBlockFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6272]
nsContainerFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 283]
nsContainerFrame::PaintChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 228]
nsHTMLContainerFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLContainerFrame.cpp, line 84]
CanvasFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLFrame.cpp, line 385]
PresShell::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  layout/base/nsPresShell.cpp, line 5822]
nsView::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  view/src/nsView.cpp, line 316]
nsViewManager::RenderDisplayListElement
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 1460]
nsViewManager::RenderViews
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 1375]
nsViewManager::Refresh
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 930]
nsViewManager::DispatchEvent
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 2047]
HandleEvent
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  widget/src/windows/nsWindow.cpp, line 1258]
nsWindow::ProcessMessage
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  widget/src/windows/nsWindow.cpp, line 4408]
nsWindow::WindowProc
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  widget/src/windows/nsWindow.cpp, line 1440]
USER32.dll + 0x27b5b (0x77d67b5b)
USER32.dll + 0x2ce12 (0x77d6ce12)
USER32.dll + 0x459d (0x77d4459d)
USER32.dll + 0x47b4 (0x77d447b4)
ntdll.dll + 0x2589f (0x77f7589f)
USER32.dll + 0x9635 (0x77d49635)
nsAppStartup::Run
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  toolkit/components/startup/src/nsAppStartup.cpp, line 151]
main
  [c:/builds/tinderbox/Fx-Mozilla1.8.0-Release/WINNT_5.2_Depend/mozilla/
  browser/app/nsBrowserApp.cpp, line 61]
kernel32.dll + 0x362b6 (0x77e962b6)

TB22159036X

Stack Signature  ntdll.dll + 0x3336f (0x77f8336f) cc5a091d
Product ID       Firefox2
Build ID         2006081606
Trigger Time     2006-08-16 10:24:09.0
Platform         Win32
Operating System Windows NT 5.1 build 2600
Module           ntdll.dll + (0003336f)
URL visited
User Comments    bug 348514 /rdmsoft
Since Last Crash 359 sec
Total Uptime     359 sec
Trigger Reason   Access violation
Source File, Line No.    N/A
Stack Trace
ntdll.dll + 0x3336f (0x77f8336f)
ntdll.dll + 0x8b7b (0x77f58b7b)
msvcrt.dll + 0x1ab2e (0x77c2ab2e)
nsAutoTextBuffer::~nsAutoTextBuffer
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsTextTransformer.cpp, line 83]
nsTextFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsTextFrame.cpp, line 1644]
nsContainerFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 283]
nsBlockFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/tables/../generic\nsBlockFrame.h, line 287]
nsBlockFrame::PaintChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6527]
nsHTMLContainerFrame::PaintDecorationsAndChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLContainerFrame.cpp, line 138]
nsBlockFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6354]
nsContainerFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 283]
nsBlockFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/tables/../generic\nsBlockFrame.h, line 287]
nsBlockFrame::PaintChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6527]
nsHTMLContainerFrame::PaintDecorationsAndChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLContainerFrame.cpp, line 138]
nsBlockFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsBlockFrame.cpp, line 6354]
nsContainerFrame::PaintChild
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 283]
nsContainerFrame::PaintChildren
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsContainerFrame.cpp, line 228]
nsHTMLContainerFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLContainerFrame.cpp, line 84]
CanvasFrame::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/generic/nsHTMLFrame.cpp, line 385]
PresShell::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  layout/base/nsPresShell.cpp, line 5866]
nsView::Paint
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  view/src/nsView.cpp, line 316]
nsViewManager::RenderDisplayListElement
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 1460]
nsViewManager::RenderViews
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 1375]
nsViewManager::Refresh
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 930]
nsViewManager::DispatchEvent
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  view/src/nsViewManager.cpp, line 2047]
HandleEvent
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  widget/src/windows/nsWindow.cpp, line 1343]
nsWindow::ProcessMessage
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  widget/src/windows/nsWindow.cpp, line 4585]
nsWindow::WindowProc
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  widget/src/windows/nsWindow.cpp, line 1531]
USER32.dll + 0x27b5b (0x77d67b5b)
USER32.dll + 0x2ce12 (0x77d6ce12)
USER32.dll + 0x459d (0x77d4459d)
USER32.dll + 0x47b4 (0x77d447b4)
ntdll.dll + 0x2589f (0x77f7589f)
USER32.dll + 0x9635 (0x77d49635)
nsAppStartup::Run
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  toolkit/components/startup/src/nsAppStartup.cpp, line 152]
main
  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/
  browser/app/nsBrowserApp.cpp, line 61]
kernel32.dll + 0x362b6 (0x77e962b6)

Comment 27

[Daniel Veditz [:dveditz]]

> Talkback crash logs disappear from the server in a week or two,

No longer, we installed massive disks last March or so and now it's more than 90 days.

Comment 28

[Daniel Veditz [:dveditz]]

> This leds me to believe that this is really not that hard to reproduce, and
> that I'm not a lone bozo.
> 
> It really does not seem to be something that can't be reproduced; and I'm
> testing it with a vanilla installation of 1.5.0.6 on three separate machines,
> with no extensions installed.

Trust me, no one thinks you're lone bozo.

Is there some systematic difference between your systems and ours? Old machines, fast machines, dual-processors, slow or fast network to the testcase site? For instance you probably hit it immediately over an in-house network.

I get 200 ms ping times to lcamtuf.coredump.cx, DSL, just tested the connection speed to be 1201/319 kbps.

Comment 29

[Thomas K. (:tom)]

(In reply to comment #23)
> I find that Mac OS X's crashreporterd's crash logs are much more
> informative than those produced by Talkback.

ffoxdie2:

Following your suggestions, my most recent crash log (I have had a few crashes before int he log) is nothing like them, and actually contains no stack info at all.  I put it in the pastebin since it's worthless: http://pastebin.mozilla.org/76

TB22230962X

Comment 30

[Steven Michaud [:smichaud] (Retired)]

> I put it in the pastebin since it's worthless:

Yes, I agree that it's worthless.  They're usually a lot better --
they include stacks for all threads and the names of all loaded shared
libraries.

> TB22230962X

Also worthless -- it's just the stack overflow that's already been
reported.

Comment 31

[georgi - hopefully not receiving bugspam]

with ffoxdie3_max.html modified so the iframe is serverd by cgi (probably to avoid caching) i crash reliably (both locally and over the internet) on linux 1.5 and 2.0-latest but don't crash on trunk.

on 1.5 the stack always involves free() and on 2.0 the crash is in different places, but showing signs of memory corruption.

didn't hit the infinite recursion case.

Comment 32

[Steven Michaud [:smichaud] (Retired)]

> with ffoxdie3_max.html modified so the iframe is serverd by cgi

I can't figure out what this means.  Could you post a copy? :-)

Comment 33

[georgi - hopefully not receiving bugspam]

(In reply to comment #32)
> I can't figure out what this means.  Could you post a copy? :-)
> 

in ffoxdie3_max.html change:
document.getElementById('foo').src = "http://lcamtuf.coredump.cx/ffoxdie3_i.html?" +Math.random();

to

document.getElementById('foo').src ="http://somewhere/cgi/ffox.pl?"+Math.random();

where ffox.pl is cgi:
#!/usr/bin/perl

print "Content-type: text/html\r\n\r\n";
print << 'EOF'

THELONGSTRING

EOF

this crashes *reliably* 1.5 on linux and 1.5 && 2.0-latest on linux and macosx ppc.

trunk didn't crash.

Comment 34

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #33)

Thank you very much for your detailed instructions.  I followed them
very carefully ... and still no crashes :-(  All my tests were with
Firefox 1.5.0.6.  Later I'll try some other versions.

I served my edited ffoxdie3_max.html and ffox.pl from Apache2 running
on my Linux box (i.e. I had a local, fast connection for both of those
files).  I even was careful not to disturb the long, strange string in
ffoxdie3_i.html -- I copied that file, changed its name to ffox.pl,
and edited around the string (rather than taking the chance of
changing it by copying and pasting).

I have _no_ idea what I'm doing "wrong" ... or "right" as the case may
be.

If you have some crash logs, please "attach" a selection of them
(using "Create a New Attachment").  As I've said above, Mac OS X
crashreporterd logs are particularly informative.  Maybe someone will
be able to glean something from them.

Daniel, did you have any better luck than I did?

Comment 35

[Daniel Veditz [:dveditz]]

Thanks Georgi, I'm seeing the non-recursion crash running the tests off localhost. TB22392645, TB22393409

Comment 36

[Jesse Ruderman]

Related to bug 317285?

Comment 37

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #35)
> TB22392645

This one is more interesting, since it makes your other one and the ones in comment 26 make a little more sense -- showing what are probably some omitted frames in those, perhaps because it crashes earlier within PaintUnicodeText.

Comment 38

[georgi - hopefully not receiving bugspam]

in my comment 33 what crashes is wrong:

crashes:
linux: 1.5-latest, 2.0-latest
macosx: 2.0 (1.5 crashed at most once iirc, so 1.5 on mac eventually may be safe).

the stacks seem of little to me - imho the crash is quite after the bug.

linux stacks (LAN and internet) from optimized downloaded 1.5.0.6:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1221896512 (LWP 4833)]
0xb7a664f2 in gdk_region_copy () from /usr/lib/libgdk-x11-2.0.so.0
(gdb) bt
#0  0xb7a664f2 in gdk_region_copy () from /usr/lib/libgdk-x11-2.0.so.0
#1  0x00009290 in ?? ()
#2  0xb75f738e in operator new () from /usr/lib/libstdc++.so.5
Previous frame inner to this frame (corrupt stack?)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1221593408 (LWP 5037)]
0xb74d52b4 in malloc_usable_size () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb74d52b4 in malloc_usable_size () from /lib/tls/libc.so.6
#1  0xb74d5a02 in free () from /lib/tls/libc.so.6
#2  0xb763fdc1 in operator delete () from /usr/lib/libstdc++.so.5
#3  0xb763fe1d in operator delete[] () from /usr/lib/libstdc++.so.5
#4  0x08274d44 in XmlInitUnknownEncodingNS ()
#5  0x0827385e in XmlInitUnknownEncodingNS ()
#6  0x0823b18e in XmlInitUnknownEncodingNS ()
#7  0x08234156 in XmlInitUnknownEncodingNS ()
#8  0x0824d341 in XmlInitUnknownEncodingNS ()
#9  0x08233ef0 in XmlInitUnknownEncodingNS ()
#10 0x0823b18e in XmlInitUnknownEncodingNS ()
#11 0x08234156 in XmlInitUnknownEncodingNS ()
#12 0x0824d341 in XmlInitUnknownEncodingNS ()
#13 0x08233ef0 in XmlInitUnknownEncodingNS ()
#14 0x0823b18e in XmlInitUnknownEncodingNS ()
#15 0x0823b0c4 in XmlInitUnknownEncodingNS ()
#16 0x0824d2d6 in XmlInitUnknownEncodingNS ()
#17 0x0824de79 in XmlInitUnknownEncodingNS ()
#18 0x08226499 in XmlInitUnknownEncodingNS ()
#19 0x083c5e1f in nsReadingIterator<unsigned short>::advance ()
#20 0x083c9476 in nsReadingIterator<unsigned short>::advance ()
#21 0x083c8ec0 in nsReadingIterator<unsigned short>::advance ()
#22 0x083c7ffb in nsReadingIterator<unsigned short>::advance ()
---Type <return> to continue, or q <return> to quit---
#23 0x083ca614 in nsReadingIterator<unsigned short>::advance ()
#24 0x083c58ac in nsReadingIterator<unsigned short>::advance ()
#25 0x081f0a7d in XmlInitUnknownEncodingNS ()
#26 0x081ea5d8 in XmlInitUnknownEncodingNS ()
#27 0x081ee452 in XmlInitUnknownEncodingNS ()
#28 0xb7c33c7a in gtk_marshal_VOID__UINT_STRING ()
   from /usr/lib/libgtk-x11-2.0.so.0

(gdb) x/i $eip
0xb74d52b4 <malloc_usable_size+2612>:   cmp    0xc(%eax),%ecx
(gdb) p/x $eax
$1 = 0x1fc

Comment 39

[georgi - hopefully not receiving bugspam]

macosx ppc stacks:

1.5
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000525
0x005b13bc in nsBlockFrame::PaintChildren ()
(gdb) bt
#0  0x005b13bc in nsBlockFrame::PaintChildren ()
#1  0x0056fe40 in nsHTMLContainerFrame::PaintDecorationsAndChildren ()
#2  0x005b1180 in nsBlockFrame::Paint ()
#3  0x004ff030 in nsContainerFrame::PaintChild ()
#4  0x005b1478 in nsBlockFrame::PaintChildren ()
#5  0x0056fe40 in nsHTMLContainerFrame::PaintDecorationsAndChildren ()
#6  0x005b1180 in nsBlockFrame::Paint ()
#7  0x004ff030 in nsContainerFrame::PaintChild ()
#8  0x004feee0 in nsContainerFrame::PaintChildren ()
#9  0x0056fc84 in nsHTMLContainerFrame::Paint ()
#10 0x005c3b2c in CanvasFrame::Paint ()
#11 0x0014c7d4 in PresShell::Paint ()
#12 0x00510688 in nsView::Paint ()
#13 0x0020831c in nsViewManager::RenderDisplayListElement ()
#14 0x00207c24 in nsViewManager::RenderViews ()
#15 0x00206a74 in nsViewManager::Refresh ()
#16 0x00209930 in nsViewManager::DispatchEvent ()
#17 0x00510274 in ViewWrapper::GetInterface ()
#18 0x006a2550 in nsWindow::DispatchEvent ()
#19 0x006a2618 in nsWindow::DispatchWindowEvent ()
#20 0x006a2178 in nsWindow::UpdateWidget ()
#21 0x006a2248 in nsWindow::UpdateWidget ()
#22 0x006a2248 in nsWindow::UpdateWidget ()
#23 0x006a2248 in nsWindow::UpdateWidget ()
#24 0x006a2248 in nsWindow::UpdateWidget ()
#25 0x006a19e4 in nsWindow::PaintUpdateRectProc ()
#26 0x006a1da0 in nsWindow::HandleUpdateEvent ()
#27 0x006a1840 in nsWindow::Update ()
#28 0x0020c230 in nsViewManager::UpdateWidgetsForView ()
#29 0x0020d04c in nsViewManager::ForceUpdate ()
#30 0x002088a0 in nsViewManager::Composite ()
#31 0x0020c7ec in nsViewManager::EnableRefresh ()
#32 0x00572d5c in nsContentSink::RefreshIfEnabled ()
#33 0x00572e58 in nsContentSink::StartLayout ()
#34 0x0052a94c in HTMLContentSink::OpenBody ()
#35 0x002a14e4 in CNavDTD::OpenBody ()
#36 0x002a1a30 in CNavDTD::OpenContainer ()
#37 0x0029e600 in CNavDTD::HandleDefaultStartToken ()
#38 0x0029f1c4 in CNavDTD::HandleStartToken ()
#39 0x0029dcb0 in CNavDTD::HandleToken ()
#40 0x0029dbc4 in CNavDTD::HandleToken ()
#41 0x0029d078 in CNavDTD::BuildModel ()
#42 0x002a538c in nsParser::BuildModel ()
#43 0x002a5090 in nsParser::ResumeParse ()
#44 0x002a6280 in nsParser::OnDataAvailable ()
#45 0x002e0a34 in nsDocumentOpenInfo::OnDataAvailable ()
#46 0x0042aabc in nsStreamListenerTee::OnDataAvailable ()
#47 0x00704c58 in nsHttpChannel::OnDataAvailable ()
#48 0x00419c00 in nsInputStreamPump::OnStateTransfer ()
#49 0x0041997c in nsInputStreamPump::OnInputStreamReady ()
#50 0x2c080ec4 in nsAStreamCopier::PostContinuationEvent_Locked ()
#51 0x2c045818 in PL_HandleEvent ()
#52 0x2c04573c in PL_ProcessPendingEvents ()
#53 0x907dc4cc in __CFRunLoopDoSources0 ()
#54 0x907db9fc in __CFRunLoopRun ()
#55 0x907db47c in CFRunLoopRunSpecific ()
#56 0x931d8980 in RunCurrentEventLoopInMode ()
#57 0x932bcf6c in GetNextEventMatchingMask ()
#58 0x932bcd20 in WNEInternal ()
#59 0x932bcc80 in WaitNextEvent ()
#60 0x006980f0 in nsMacMessagePump::GetEvent ()
#61 0x0069804c in nsMacMessagePump::DoMessagePump ()
#62 0x00300edc in nsAppShell::Run ()
#63 0x003a13b8 in nsAppStartup::Run ()
#64 0x000126ec in XRE_main ()
#65 0x0000d768 in start ()
#66 0x0000d5e8 in start ()
(gdb) x/i $pc
0x5b13bc <_ZN12nsBlockFrame13PaintChildrenEP13nsPresContextR19nsIRenderingContextRK6nsRect17nsFramePaintLayerj+308>:    lwz     r9,44(r2)
(gdb) x/i $pc
0x5b13bc <_ZN12nsBlockFrame13PaintChildrenEP13nsPresContextR19nsIRenderingContextRK6nsRect17nsFramePaintLayerj+308>:    lwz     r9,44(r2)

2.0:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000068a
0x90004688 in szone_malloc ()
(gdb) bt
#0  0x90004688 in szone_malloc ()
#1  0x0200016c in ?? ()
#2  0x2c0536b4 in NS_Alloc_P ()
#3  0x00478c40 in nsUnicodeRenderingToolkit::GetTextSegmentDimensions ()
#4  0x00479a3c in nsUnicodeRenderingToolkit::GetTextDimensions ()
#5  0x004798c0 in nsUnicodeRenderingToolkit::GetWidth ()
#6  0x0012aea4 in nsRenderingContextMac::GetWidthInternal ()
#7  0x004763cc in nsRenderingContextImpl::DrawString ()
#8  0x006d93ec in nsTextFrame::PaintUnicodeText ()
#9  0x006d7b10 in nsTextFrame::Paint ()
#10 0x004bcf1c in nsContainerFrame::PaintChild ()
#11 0x006c8bb8 in nsBlockFrame::PaintChildren ()
#12 0x00590930 in nsHTMLContainerFrame::PaintDecorationsAndChildren ()
#13 0x006c88c0 in nsBlockFrame::Paint ()
#14 0x004bcf1c in nsContainerFrame::PaintChild ()
#15 0x006c8bb8 in nsBlockFrame::PaintChildren ()
#16 0x00590930 in nsHTMLContainerFrame::PaintDecorationsAndChildren ()
#17 0x006c88c0 in nsBlockFrame::Paint ()
#18 0x004bcf1c in nsContainerFrame::PaintChild ()
#19 0x004bcdcc in nsContainerFrame::PaintChildren ()
#20 0x00590774 in nsHTMLContainerFrame::Paint ()
#21 0x006f0878 in CanvasFrame::Paint ()
#22 0x0014fdcc in PresShell::Paint ()
#23 0x004e5904 in nsView::Paint ()
#24 0x001f70ac in nsViewManager::RenderDisplayListElement ()
#25 0x001f69b4 in nsViewManager::RenderViews ()
#26 0x001f5804 in nsViewManager::Refresh ()
#27 0x001f86c0 in nsViewManager::DispatchEvent ()
#28 0x004e54f0 in ViewWrapper::GetInterface ()
#29 0x006108b0 in nsWindow::DispatchEvent ()
#30 0x00610978 in nsWindow::DispatchWindowEvent ()
#31 0x006104d8 in nsWindow::UpdateWidget ()
#32 0x006105a8 in nsWindow::UpdateWidget ()
#33 0x006105a8 in nsWindow::UpdateWidget ()
#34 0x006105a8 in nsWindow::UpdateWidget ()
#35 0x006105a8 in nsWindow::UpdateWidget ()
#36 0x006105a8 in nsWindow::UpdateWidget ()
#37 0x006105a8 in nsWindow::UpdateWidget ()
#38 0x006105a8 in nsWindow::UpdateWidget ()
#39 0x006105a8 in nsWindow::UpdateWidget ()
#40 0x006105a8 in nsWindow::UpdateWidget ()
#41 0x0060fef8 in nsWindow::PaintUpdateRect ()
#42 0x00610130 in nsWindow::HandleUpdateEvent ()
#43 0x0060fcf4 in nsWindow::Update ()
#44 0x00296ea8 in nsMacWindow::Update ()
#45 0x00294a84 in nsMacWindow::WindowEventHandler ()
#46 0x931d7794 in DispatchEventToHandlers ()
#47 0x931d6eec in SendEventToEventTargetInternal ()
#48 0x931d6d68 in SendEventToEventTargetWithOptions ()
#49 0x932aa088 in HandleWindowEvent ()
#50 0x931de030 in ToolboxEventDispatcherHandler ()
#51 0x931d79e4 in DispatchEventToHandlers ()
#52 0x931d6eec in SendEventToEventTargetInternal ()
#53 0x931ddc8c in SendEventToEventTarget ()
#54 0x9321e9a0 in ToolboxEventDispatcher ()
#55 0x9321e92c in HLTBEventDispatcher ()
#56 0x9321cee4 in RunApplicationEventLoop ()
#57 0x0028fb80 in nsAppShell::Run ()
#58 0x0032cde8 in nsAppStartup::Run ()
#59 0x000127ec in XRE_main ()
#60 0x0000d768 in start ()
#61 0x0000d5e8 in start ()

Comment 40

[Daniel Veditz [:dveditz]]

Could this be the same thing as bug 345071? My crashes in nsTextFrame::PrepareUnicodeText happen a bit before the spot patched in that bug (which looks like it involves BIDI text). Now that I can reproduce this reliably on my own machine I'll try trunk builds bracketing that checkin and see.

Comment 41

[Daniel Veditz [:dveditz]]

I can't reproduce the crash on trunk, before or after roc's Aug 15 checkin.

Comment 42

[georgi - hopefully not receiving bugspam]

valgrind may help debug this.

timings that work for me on lan with static iframe:

	if (counter < 3) {
...
setTimeout('foo()', 2150 * counter);

^^dependent on machine speed.

valgrind detects invlid write and exits due to "the 'impossible' happened".

don't have debug branch ATM

Comment 43

[georgi - hopefully not receiving bugspam]

on debug 1.8.0-latest

get this assertion:
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /opt/joro/firefox-branch/mozilla/layout/base/nsPresShell.cpp, line 7170
++DOMWINDOW == 13
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /opt/joro/firefox-branch/mozilla/layout/base/nsPresShell.cpp, line 7170
++DOMWINDOW == 14
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file /opt/joro/firefox-branch/mozilla/layout/base/nsPresShell.cpp, line 7170
###!!! ASSERTION: yikes - we just overwrote memory: 'indexp <= aIndexBuffer->mBuffer + aIndexBuffer->mBufferLen', file /opt/joro/firefox-branch/mozilla/layout/generic/nsTextFrame.cpp, line 1925
Break: at file /opt/joro/firefox-branch/mozilla/layout/generic/nsTextFrame.cpp, line 1925

Comment 44

[Jesse Ruderman]

CCing roc, who has fixed several nsTextFrame bugs recently.

Comment 45

[Daniel Veditz [:dveditz]]

> ###!!! ASSERTION: yikes - we just overwrote memory: 'indexp <=
> aIndexBuffer->mBuffer + aIndexBuffer->mBufferLen', file
> /opt/joro/firefox-branch/mozilla/layout/generic/nsTextFrame.cpp, line 1925

That's the assertion from roc's bug 345071 I mentioned in comment 40. Maybe they are the same. I couldn't reproduce this bug on the trunk just prior to that patch, I guess I'll have to try porting the patch to a branch and do a non-debug build (since I can't reproduce the timing in a debug build either).

Comment 46

[Daniel Veditz [:dveditz]]

On an optimized-with-symbols FF1.5.0.7 I get a completely different stack. Its possible the heap was already trashed by the nsTextFrame bug and I simply randomly crashed somewhere else, so I'm still going to try applying roc's patch.

  _RtlAllocateHeap@12() + 0xc0a	
> _heap_alloc(unsigned int size=0x00000278) Line 212	C
  _nh_malloc(unsigned int size=0x00000278, int nhFlag=0x00000000) Line 113	C
  malloc(unsigned int size=0x00000278) Line 54 + 0xf	C
  operator new(unsigned int size=0x00000278) Line 12 + 0x6	C++
  nsIDocument::operator new(unsigned int sz=0x00000278) Line 116 + 0xa	C++
  NS_NewHTMLDocument(nsIDocument * * aInstancePtrResult=0x0013f524) Line 195 + 0xa	C++
  CreateHTMLDocument(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0013f590) Line 547 + 0x21	C++
  nsGenericFactory::CreateInstance(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0013f590) Line 79 + 0xe	C++
  nsComponentManagerImpl::CreateInstance(const nsID & aClass={...}, nsISupports * aDelegate=0x00000000, const nsID & aIID={...}, void * * aResult=0x00f382d0) Line 1899 + 0x10	C++
  CallCreateInstance(const nsID & aCID={...}, nsISupports * aDelegate=0x00000000, const nsID & aIID={...}, void * * aResult=0x0013f590) Line 158	C++
  nsCreateInstanceByCID::operator()(const nsID & aIID={...}, void * * aInstancePtr=0x0013f590) Line 199 + 0x16	C++
  nsCOMPtr_base::assign_from_helper(const nsCOMPtr_helper & helper={...}, const nsID & iid={...}) Line 150 + 0x10	C++
  nsContentDLF::CreateDocument(const char * aCommand=0x011524b0, nsIChannel * aChannel=0x00000000, nsILoadGroup * aLoadGroup=0x0333a0a0, nsISupports * aContainer=0x0334c26c, const nsID & aDocumentCID={...}, nsIStreamListener * * aDocListener=0x032dbf6c, nsIContentViewer * * aDocViewer=0x0013f6fc) Line 420	C++
  nsContentDLF::CreateInstance(const char * aCommand=0x011524b0, nsIChannel * aChannel=0x0338949c, nsILoadGroup * aLoadGroup=0x0333a0a0, const char * aContentType=0x03384fc8, nsISupports * aContainer=0x0334c26c, nsISupports * aExtraInfo=0x00000000, nsIStreamListener * * aDocListener=0x032dbf6c, nsIContentViewer * * aDocViewer=0x0013f6fc) Line 231 + 0x1f	C++
  nsDocShell::NewContentViewerObj(const char * aContentType=0x03384fc8, nsIRequest * request=0x00000000, nsILoadGroup * aLoadGroup=0x0333a0a0, nsIStreamListener * * aContentHandler=0x032dbf6c, nsIContentViewer * * aViewer=0x0013f6fc) Line 5802 + 0x2e	C++
  nsDocShell::CreateContentViewer(const char * aContentType=0x03384fc8, nsIRequest * request=0x0338949c, nsIStreamListener * * aContentHandler=0x032dbf6c) Line 5653	C++
  nsDSURIContentListener::DoContent(const char * aContentType=0x03384fc8, int aIsContentPreferred=0x00000000, nsIRequest * request=0x0338949c, nsIStreamListener * * aContentHandler=0x032dbf6c, int * aAbortProcess=0x0338949c) Line 131	C++
  nsDocumentOpenInfo::TryContentListener(nsIURIContentListener * aListener=0x032daf98, nsIChannel * aChannel=0x032dbf6c) Line 776	C++
  nsDocumentOpenInfo::DispatchContent(nsIRequest * request=0x0013f590, nsISupports * aCtxt=0x012316fd) Line 500 + 0x12	C++
  nsDocumentOpenInfo::OnStartRequest(nsIRequest * request=0x0013f590, nsISupports * aCtxt=0x012316fd) Line 345 + 0xd	C++
  nsHttpChannel::CallOnStartRequest() Line 722 + 0x11	C++
  nsHttpChannel::ProcessNormal() Line 891	C++
  nsHttpChannel::ProcessResponse() Line 814 + 0x7	C++
  nsHttpChannel::OnStartRequest(nsIRequest * request=0x03393918, nsISupports * ctxt=0x00000000) Line 3971 + 0x8	C++
  nsInputStreamPump::OnStateStart() Line 385	C++
  nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x03393880) Line 347	C++
  nsInputStreamReadyEvent::EventHandler(PLEvent * plevent=0x03393974) Line 120	C++
  PL_HandleEvent(PLEvent * self=0x03393974) Line 689	C
  PL_ProcessPendingEvents(PLEventQueue * self=0x00eba9c8) Line 623 + 0x6	C
  _md_EventReceiverProc(HWND__ * hwnd=0x00240466, unsigned int uMsg=0x0000c201, unsigned int wParam=0x00000000, long lParam=0x00eba9c8) Line 1409	C
  77d48744	
  77d48826	
  77d489dd	
  77d49412	
  77d48a20	
  nsAppShell::Run() Line 159	C++
  nsAppStartup::Run() Line 151	C++
  XRE_main(int argc=0x00000278, char * * argv=0x0013f590, const nsXREAppData * aAppData=0x012316fd) Line 2378	C++
  main(int argc=0x00000003, char * * argv=0x008e2e60) Line 61 + 0x12	C++
  WinMain(HINSTANCE__ * __formal=0x00400000, HINSTANCE__ * __formal=0x00400000, char * args=0x0016231a, HINSTANCE__ * __formal=0x00400000) Line 70 + 0x17	C++
  WinMainCRTStartup() Line 390 + 0x1b	C
  7c816fd7	

Comment 47

[georgi - hopefully not receiving bugspam]

(In reply to comment #46)
> On an optimized-with-symbols FF1.5.0.7 I get a completely different stack. Its
> possible the heap was already trashed by the nsTextFrame bug and I simply

for me the crashes are with different stack, which is consistent with screwed heap. 
debug branch crashes with default timings over the internet, but not on the lan.

not sure if trunk is safe - with longer string and different timings trunk crashed once in free(), but couldn't reproduce it later.

is it sure that the warning about overwriting memory indeed causes the problem?

Comment 48

[Daniel Veditz [:dveditz]]

> is it sure that the warning about overwriting memory indeed causes the problem?

Not sure, no, but it's a reasonable guess given the symptoms.

Starting with a build that consistently reproduced the crash (the stack in comment 46 and others that looked like comment 8) I no longer crashed on the testcase after applying the patch from bug 345071. I think we've nailed it.

The one nagging doubt is that the bug 345071 heap overflow should have been entirely reproduceable, it should not have required reload timing games.

Comment 49

[georgi - hopefully not receiving bugspam]

can't see bug 345071 so can't comment on it.

believe that the indexp issue can be easily fixed with 2 macros - one for the condition in the loop and one checking for overflow. this may be a kludge.

just informing for overflow and then continuing execution is strange coding practice.

Comment 50

[Daniel Veditz [:dveditz]]

bug 345071 has been checked into the branch, available as "1.5.0.7" builds at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0/ (or  go up a directory and pick an explicit date Aug 26 or later).

The patch resolves the problem *I* see, but I've never been quite sure I'm seeing the same thing Michal is reporting. In addition his posts to Bugtraq seemed to indicate he saw a different problem with ffoxdie3 than the original ffoxdie, and bug 345071 addresses what I saw with ffoxdie3.

Michal: does this resolve the original problem, or are you still seeing it even after that fix.

Comment 51

[Daniel Veditz [:dveditz]]

qawanted: please verify that the checkin for bug 345071 did in fact fix this one.

Comment 52

[Bob Clary [:bc] (inactive)]

(In reply to comment #51)
> qawanted: please verify that the checkin for bug 345071 did in fact fix this
> one.
> 

I tried 1.5.0.6, 1.5.0.7, 1.5.0 debug, 1.5.0 debug minus bug 345071 winxp on local versions of the testcases in this bug and could only reproduce the recursion crash on any of them. I can't verify anything.

Comment 53

[georgi - hopefully not receiving bugspam]

i crashed before (no recursion), but don't crash after the patch.

note that this may mean that the timings/lengths after the patch are different (tried different lengths/timings without crash).

Comment 54

[Carsten Book [:Tomcat]]

Crash with Windows on both Testcases : Talkback TB23012138W and TB23012537Z with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060906 Firefox/1.5.0.7

Comment 55

[Marcia Knous [:marcia]]

I see both testcases crashing in FF beta2 on Windows - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2. On the Mac I crashed both testcases using today's Bon Echo nightly. 

Comment 56

[Daniel Veditz [:dveditz]]

(In reply to comment #54)
> Crash with Windows on both Testcases : Talkback TB23012138W and TB23012537Z

Those are both the less interesting stack-overflow problem. Is there a bug filed on limiting the recursion levels and giving up at a sane point?

Comment 57

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We try to avoid this kind of stack overflow by limiting the depth of the content tree. At least, the HTML parser tries to. Dunno about XML.

Comment 58

[georgi - hopefully not receiving bugspam]

don't crash with ffoxdie3* but crash with ffoxdie.html - the stack looks like too much recursion.

Comment 59

[Daniel Veditz [:dveditz]]

This bug has been given the CVE references
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4253 (ffoxdie) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4261 (ffoxdie3)

I guess two separate ones in case they turn out to be different issues

Comment 60

[Jesse Ruderman]

(In reply to comment #56)

> Those are both the less interesting stack-overflow problem. Is there a bug
> filed on limiting the recursion levels and giving up at a sane point?

Bug 323394 covers this too-much-recursion crash.

Comment 61

[Alexander Sack]

Dan,

for me both testcases crash 100% reproducible using the official 1.5.0.7 tarball for linux - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7.

Comment 62

[IU]

I too am crashing (with JavaScript enabled) at http://lcamtuf.coredump.cx/ffoxdie.html

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060918 BonEcho/2.0 ID:2006091804

Comment 63

[Marco Bonardo [:mak]]

why is this marked as fixed, everybody is crashing here http://lcamtuf.coredump.cx/ffoxdie.html with FX2.0 RC1...

Comment 64

[Alexander Sack]

(In reply to comment #63)
> why is this marked as fixed, everybody is crashing here
> http://lcamtuf.coredump.cx/ffoxdie.html with FX2.0 RC1...
> 

What you see here is the too-deep-recursion crash which is dealt with in bug 323394.

This bug is for the "NOT due to too-much-recursion" (See bug title) issue, which the reporter intended to show.

Comment 65

[Marco Sousa]

NOT FIXED in FIREFOX 2.0 RC3 and FINAL

Comment 66

[Diego Calleja]

It certainly doesn't happen here in firefox 2 final, current edgy version, any of the three exploits (ffdie.html, ffdie2.html, ffdie3.html) seem to do anything

Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)

BTW security webs are already reporting this bug as "first firefox 2 security bug" - http://www.kriptopolis.org/firefox-2-vulnerable

Comment 67

[Diego Calleja]

By the way, I don't know if it may be related, but my ubuntu firefox copy os being compiled with gcc 4.1 SSP stack protection (-fstack-protector)

Comment 68

[IU]

Definitely NOT FIXED in Firefox 2.0 Final. Win XP SP2

For those who can't reproduce it, make sure you have JavaScript enabled.

Comment 69

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Just because you crash on the testcase doesn't mean you're seeing *this* bug.  You're probably seeing bug 323394, which does not have the potential for remote code execution.