Closed Bug 348514 (CVE-2006-4253) Opened 18 years ago Closed 18 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: u88484, Assigned: dveditz)

References

(
URL
)

Details

(5 keywords, Whiteboard: [sg:critical?] apears fixed by 345071)

Crash Data

Attachments

(2 files)

testcase
1.12 KB, text/html
Details
testcase 2
1.12 KB, text/html
Details 
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
Summary: (SelectorMatches]) Crash @ http://lcamtuf.coredump.cx/ffoxdie.html → (SelectorMatches) Crash @ http://lcamtuf.coredump.cx/ffoxdie.html
(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.
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 ;)
Ugh...I ran the test case on a debug executable with MSVC attached and got a BSOD. Not helpful.
Camino Version 2006061318 (1.0.2)
TB22051950Y
OS: Windows XP → All
Hardware: PC → All
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout
QA Contact: ian → layout
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).

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

(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.
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.

if you get a bsod, file a bug indicating a crash and i'll walk you through finding which driver is buggy.
Keywords: testcase
Severity: major → critical
Summary: (SelectorMatches) Crash @ http://lcamtuf.coredump.cx/ffoxdie.html → Crash in [@ SelectorMatches] @ http://lcamtuf.coredump.cx/ffoxdie.html
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.
Flags: blocking1.8.1?
Flags: blocking1.8.0.7?
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.
Flags: blocking1.8.1? → blocking1.8.1-
(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
> 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 :-)

(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
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.
(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?
> 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.
> 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.

(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
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.

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?
> 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.

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)

> 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.
> 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.
(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
> 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.

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.


> 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? :-)
(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.
(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?

Thanks Georgi, I'm seeing the non-recursion crash running the tests off localhost. TB22392645, TB22393409
Related to bug 317285?
(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.
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




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 ()
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.
I can't reproduce the crash on trunk, before or after roc's Aug 15 checkin.
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
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

CCing roc, who has fixed several nsTextFrame bugs recently.
Summary: Crash in [@ SelectorMatches] @ http://lcamtuf.coredump.cx/ffoxdie.html → Crash at http://lcamtuf.coredump.cx/ffoxdie.html (NOT due to too-much-recursion) [@ nsTextFrame::PrepareUnicodeText] [@ nsAutoIndexBuffer::~nsAutoIndexBuffer]
> ###!!! 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).
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	

(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?
> 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.
Assignee: nobody → dveditz
Depends on: 345071
Flags: blocking1.8.1?
Flags: blocking1.8.1-
Flags: blocking1.8.0.7?
Flags: blocking1.8.0.7+
Whiteboard: apears fixed by 345071
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.
Flags: blocking1.8.1? → blocking1.8.1+
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.
qawanted: please verify that the checkin for bug 345071 did in fact fix this one.
Keywords: fixed1.8.0.7, fixed1.8.1, qawanted
(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.

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).

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
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. 
(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?
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Summary: Crash at http://lcamtuf.coredump.cx/ffoxdie.html (NOT due to too-much-recursion) [@ nsTextFrame::PrepareUnicodeText] [@ nsAutoIndexBuffer::~nsAutoIndexBuffer] → Crash at http://lcamtuf.coredump.cx/ffoxdie.html (NOT due to too-much-recursion) [@ nsTextFrame::PrepareUnicodeText] [@ nsAutoIndexBuffer::~nsAutoIndexBuffer] (CVE-2006-4253)
Whiteboard: apears fixed by 345071 → [sg:critical?] apears fixed by 345071
don't crash with ffoxdie3* but crash with ffoxdie.html - the stack looks like too much recursion.
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
Alias: CVE-2006-4253
(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.
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.


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

why is this marked as fixed, everybody is crashing here http://lcamtuf.coredump.cx/ffoxdie.html with FX2.0 RC1...
(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.
NOT FIXED in FIREFOX 2.0 RC3 and FINAL
Depends on: ffoxdie
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
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)
Definitely NOT FIXED in Firefox 2.0 Final. Win XP SP2

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

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.
Crash Signature: [@ nsTextFrame::PrepareUnicodeText] [@ nsAutoIndexBuffer::~nsAutoIndexBuffer]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: