Last Comment Bug 289864 - (imageBSOD) Page crashes system (blue screen) with oversized image
(imageBSOD)
: Page crashes system (blue screen) with oversized image
Status: RESOLVED WORKSFORME
[sg:dos] system crash
: crash, fixed-aviary1.0.5, fixed1.7.9
Product: Core Graveyard
Classification: Graveyard
Component: Image: Painting (show other bugs)
: 1.7 Branch
: x86 Windows XP
: -- critical with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.livejournal.com/users/deep...
: 295383 297554 297695 297701 297879 298034 298080 298147 298641 298660 298781 299355 300288 300461 300480 300665 314574 354783 (view as bug list)
Depends on: 284716 284978
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-10 22:56 PDT by Taral
Modified: 2011-08-05 21:16 PDT (History)
41 users (show)
chase: blocking1.7.9+
chase: blocking‑aviary1.0.5+
shaver: blocking1.8b5-
bob: in‑testsuite+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
WARNING!! BLUE SCREEN!! testcase (83.61 KB, text/plain)
2005-04-13 12:12 PDT, Daniel Veditz [:dveditz]
no flags Details
image for testcase (41.20 KB, image/jpeg)
2005-05-24 18:25 PDT, Daniel Veditz [:dveditz]
no flags Details
simplified testcase (100 bytes, text/html)
2005-05-24 18:28 PDT, Daniel Veditz [:dveditz]
no flags Details
Patch to improve robustness in the face of erroneous user supplied data (855 bytes, patch)
2005-05-25 07:36 PDT, Ben Fowler
no flags Details | Diff | Review
Patch to improve robustness in the face of erroneous user supplied data (791 bytes, patch)
2005-05-25 07:45 PDT, Ben Fowler
no flags Details | Diff | Review
Patch to improve robustness in the face of erroneous user supplied data (901 bytes, patch)
2005-05-25 07:57 PDT, Ben Fowler
no flags Details | Diff | Review
alt testcase : WinXP html using large IMG dimensions via CSS (374 bytes, text/html)
2005-06-23 13:01 PDT, Lloyd D Budd
no flags Details

Description Taral 2005-04-10 22:56:20 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Yes, this isn't really a firefox bug. The page tries to display an image with
height="9999999" width="9999999" -- this blue-screens windows.

Reproducible: Always

Steps to Reproduce:
Comment 1 Taral 2005-04-10 22:57:05 PDT
I filed this because firefox should probably filter really huge images like
this, especially if they can be used to exploit OS-level bugs.
Comment 2 Daniel Veditz [:dveditz] 2005-04-11 14:22:46 PDT
The page appears to be gone or there's a typo in
http://www.livejournal.com/community/roflcl/404836.html. Do you have a copy of
the page source and image?

We do filter out images ~64k on a side to prevent math overflows, but images
anywhere near that large would likely exhaust a machine's memory. We should
handle the OS telling us there's no more memory, but it appears the OS itself
can't handle it.

Specifying height and width as 9999999 in the <img> tag for smaller images
affects layout, but doesn't cause problems when I test it.

Unless you can find this page so we can test to see what it really is I'm going
to assume this is the memory issue described in bug 214146 (don't be fooled by
the png-specific summary)

*** This bug has been marked as a duplicate of 214146 ***
Comment 3 Taral 2005-04-12 11:08:11 PDT
The crash code is in http://jameth.whatthefuck.com/apr2005/11/deeplolz.txt.

This is Windows-specific. The duplicate bug appears to be a Linux bug.
Comment 4 Taral 2005-04-12 12:26:41 PDT
This now has been posted to Bugtraq.
Comment 5 Daniel Veditz [:dveditz] 2005-04-12 14:02:53 PDT
Thanks. I didn't crash with that one, either, but some of the included images
are already 404's -- I guess those might have been the big ones?

It does chew up a lot of memory though, could kill a box with less.

Clearing confidential flag, no point if this is on Bugtraq. We'll just get dupes.
Comment 6 Chase Phillips 2005-04-12 14:11:05 PDT
blocking-aviary1.0.4?
Comment 7 Taral 2005-04-13 11:09:36 PDT
Note updated URL. Not sure how long it'll last, since the previous incarnation
got killed.
Comment 8 Daniel Veditz [:dveditz] 2005-04-13 12:12:17 PDT
Created attachment 180605 [details]
WARNING!! BLUE SCREEN!! testcase

Captured the latest page. This does not run up memory or CPU usage (my initial
guess), the blue screen message says something about a driver error.

adding with the wrong MIME type intentionally to protect people
Comment 9 Taral 2005-04-13 12:14:59 PDT
(I note that any poor IE users will still get bluescreened by text/plain.)

Something causes the video driver to go into a long-running routine, eventually
triggering a watchdog timer in the kernel.
Comment 10 Stuart Parmenter 2005-04-14 19:12:09 PDT
the test image that was in the bug is now gone ;/  can someone find another
version that breaks?
Comment 11 Taral 2005-04-16 22:04:26 PDT
Is bug 166862 related? (found by njyoder)
Comment 12 Simon 2005-05-14 14:54:15 PDT
(In reply to comment #10)
> the test image that was in the bug is now gone ;/  can someone find another
> version that breaks?

http://ha.ckers.org/imagecrash.html crashed me 5 minutes ago.
The image is only 640x480 in size, here's the source if the page goes down:

<HTML>
  <BODY>
    <IMG SRC="./imagecrash.jpg" width="9999999" height="9999999">
  </BODY>
</HTML>

That's it.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4
Comment 13 Daniel Veditz [:dveditz] 2005-05-24 18:25:53 PDT
Created attachment 184456 [details]
image for testcase
Comment 14 Daniel Veditz [:dveditz] 2005-05-24 18:28:11 PDT
Created attachment 184457 [details]
simplified testcase

Simplified testcase from bug 295383
Comment 15 Daniel Veditz [:dveditz] 2005-05-24 18:29:58 PDT
*** Bug 295383 has been marked as a duplicate of this bug. ***
Comment 16 Daniel Veditz [:dveditz] 2005-05-24 18:48:16 PDT
This appears OK on the Deer Park Alpha, could it be fixed by the large-value
colspan/rowspan bug 141818?
Comment 17 Daniel Veditz [:dveditz] 2005-05-24 19:02:50 PDT
(In reply to comment #16)
> This appears OK on the Deer Park Alpha, could it be fixed by the large-value
> colspan/rowspan bug 141818?

No: despite the testcase similarity of using "9999999" attribute values to cause
a crash, that fix was specifically to the colspan and rowspan attribute parser.
Comment 18 Ben Fowler 2005-05-25 07:36:35 PDT
Created attachment 184497 [details] [diff] [review]
Patch to improve robustness in the face of erroneous user supplied data

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050517
Firefox/1.0+

The testcase in comment 8 crashes for me.

Whilst testing this, I found the following code path: 

The function nsLineLayout::FreeSpan(PerSpanData* psd)
at http://lxr.mozilla.org/seamonkey/source/layout/generic/nsLineLayout.cpp#733
can be called with the argument psd containing null. Since we try to 
dereference it, I suggest this guard
Comment 19 Ben Fowler 2005-05-25 07:45:57 PDT
Created attachment 184498 [details] [diff] [review]
Patch to improve robustness in the face of erroneous user supplied data

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050517
Firefox/1.0+

The testcase in comment 8 crashes for me.

Whilst testing this, I found the following code path: 

The function nsLineLayout::EndLineReflow()
at http://lxr.mozilla.org/seamonkey/source/layout/generic/nsLineLayout.cpp#350
can be called with the member mRootSpan already nsnull. It seems unnecessary to

'Free' it, or most probably to do anything else, I suggest this guard.
Comment 20 Ben Fowler 2005-05-25 07:57:09 PDT
Created attachment 184499 [details] [diff] [review]
Patch to improve robustness in the face of erroneous user supplied data

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050517
Firefox/1.0+

The testcase in comment 8 crashes for me.

Whilst testing this, I found the following code path: 

At http://lxr.mozilla.org/seamonkey/source/layout/generic/nsLineLayout.cpp#830
we initialise the local variable psd an use its value on the next line,
unfortunately, it is possible for psd to contain null at this point. 
I suggest this guard.

Now it is my belief that these patches are well downstream of the site of 
the cause of this crash, but while it is easily reproducible, I can take
the opportunity to add some error handling.
Comment 21 usererror3000 2005-05-27 17:55:35 PDT
i haven't tryed these specific test cases, but this one
http://www.tinyurl.com/dsprr crashed mine.
note this one somehow puts up an away message w/ the url if you have the offical
version of aim, luckly i use gaim so it didn't work on me.

I noticed it crashes my laptop, 2.8GHz Pentium 4 HT, 512MB ram (with 64 MB
shared video memory, ATI Radeon Mobility 9000) caused BSOD, and caused my
graphics driver to crash

same thing on my desktop, 3 Ghz Pentium 4 HT, 512MB RAM, 256 MB Radeon 9800, 512
MB ram.

it seems to be an all-browser exploit, works on IE too.

Comment 22 Asa Dotzler [:asa] 2005-06-07 15:21:13 PDT
This appears to be fixed on the trunk. If we can get some help identifying the
build that corrected the crash on the trunk that would be great because it might
give us the checkin that fixed things there. if that's a simple fix, then we can
consider taking that on the branch. 
Comment 23 Daniel Veditz [:dveditz] 2005-06-14 11:24:26 PDT
Another site using this trick: http://winboot.mine.nu/

Opera does not crash.
Comment 24 Daniel Veditz [:dveditz] 2005-06-14 11:27:50 PDT
*** Bug 297554 has been marked as a duplicate of this bug. ***
Comment 25 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-06-14 13:59:57 PDT
*** Bug 297695 has been marked as a duplicate of this bug. ***
Comment 26 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-06-14 14:02:20 PDT
*** Bug 297701 has been marked as a duplicate of this bug. ***
Comment 27 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-06-15 23:54:34 PDT
*** Bug 297879 has been marked as a duplicate of this bug. ***
Comment 28 Daniel Veditz [:dveditz] 2005-06-17 23:05:59 PDT
*** Bug 298034 has been marked as a duplicate of this bug. ***
Comment 29 Daniel Veditz [:dveditz] 2005-06-18 10:17:21 PDT
*** Bug 298080 has been marked as a duplicate of this bug. ***
Comment 30 Daniel Veditz [:dveditz] 2005-06-19 02:36:30 PDT
*** Bug 298147 has been marked as a duplicate of this bug. ***
Comment 31 Daniel Veditz [:dveditz] 2005-06-19 10:38:29 PDT
Apparently Microsoft fixed this in their latest round of windows security
updates: In looking for what might have fixed this on the trunk I walked back to
the branch point, then out the branch all the way to the release I know I used
to confirm this bug (several times in different test cases).

I'll have to find an unpatched system to try to narrow this down (or we could
just point fingers at Microsoft and ignore it since the upcoming 1.1 had this
fixed anyway).
Comment 32 Daniel Veditz [:dveditz] 2005-06-19 17:59:13 PDT
On Win XP this was fixed between 2005-03-04-07-trunk and 2005-03-05-07-trunk.
Not exactly sure when the nightlies pull, but the fix is definitely in this range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-03-04+04%3A00&maxdate=2005-03-05+08%3A00&cvsroot=%2Fcvsroot

The only fix that jumps out at me is Paper's patch for bug 284716. That patch
looks like it's Win2k/XP only -- does Win98/ME crash on these testcases in
1.0.x, and if so does it still crash in Deer Park? (QA note: the latest
microsoft security updates, for winxp at least, appear to also block this crash.
Make sure you test a windows box without the latest updates).
Comment 33 Daniel Veditz [:dveditz] 2005-06-19 19:48:47 PDT
(In reply to comment #32)
> The only fix that jumps out at me is Paper's patch for bug 284716. That patch
> looks like it's Win2k/XP only -- does Win98/ME crash on these testcases[?]

The patch for bug 284716 stops the crash on Win XP (both Firefox and Mozilla
1.7), I recommend we take it for the branches. Doesn't look like it will help
Win98, but it's not been confirmed the problem exists there.
Comment 34 Daniel Veditz [:dveditz] 2005-06-20 14:45:18 PDT
We're not going to take this on the branches, the fix for bug 284716 caused
regressions and is snowballing into a bigger change than we're comfortable with
for a security release (it just moves the DOS somewhere else).

The crash is fixed on the trunk. People not ready to upgrade to the
alpha-quality trunk can apply Microsoft's June 2005 security updates and protect
themselves.
Comment 35 Lloyd D Budd 2005-06-21 16:13:05 PDT
In reply to Comment #31 From Daniel Veditz  2005-06-19 10:38 PDT :
> Apparently Microsoft fixed this in their latest round of windows 
> security updates
It still occurs on up to date WinXP .

Also , we have only found this in WinXP .  Not in Win2k , or Win98/ME .
Comment 36 Daniel Veditz [:dveditz] 2005-06-23 11:37:19 PDT
(In reply to comment #35)
> In reply to Comment #31 From Daniel Veditz  2005-06-19 10:38 PDT :
> > Apparently Microsoft fixed this in their latest round of windows 
> > security updates
> It still occurs on up to date WinXP .

Confirmed the crash still occurs on another fully updated machine (on the 1.0.x
branch). I guess the fact that my main dev machine no longer crashes is just a
happy accident, not an intentional fix in the latest Microsoft updates.
Comment 37 Chase Phillips 2005-06-23 12:31:55 PDT
Setting blocking1.7.9 and blocking-aviary1.0.5 per 1.0.5 meeting.
Comment 38 Lloyd D Budd 2005-06-23 12:56:33 PDT
This bug is currently marked fixed , but it is not fixed in 1.0.x 
ENV:
firefox/nightly/2005-06-23-05-aviary1.0.1/firefox-1.0.5.en-US.win32.installer.exe
23-Jun-2005 08:29  4.6M  
still repros the issue (on a WinXP up to date) computer (with one of the
numerous video h/w cfg that is exposed to this MS bug) .

Other than CSS are there other interesting variations of the testcase ?
Comment 39 Lloyd D Budd 2005-06-23 13:01:16 PDT
Created attachment 187146 [details]
alt testcase : WinXP html using large IMG dimensions via CSS

Alternate testcase : WinXP html using large IMG dimensions via CSS
Comment 40 Jay Patel [:jay] 2005-06-23 13:02:48 PDT
Lloyd:  It is marked fixed because this is fixed on the Trunk.  That is how we
track progress on the development tree.  The "blocking-aviary1.0.5+" and
"blocking1.7.9+" flags are used to track whether or not we need to fix this on
the branches (eg. Firefox 1.0.x).  We are looking into fixing this for those
releases. 
Comment 41 Daniel Veditz [:dveditz] 2005-06-23 23:56:11 PDT
*** Bug 298641 has been marked as a duplicate of this bug. ***
Comment 42 Daniel Veditz [:dveditz] 2005-06-24 09:02:58 PDT
*** Bug 298660 has been marked as a duplicate of this bug. ***
Comment 43 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-06-25 14:34:18 PDT
*** Bug 298781 has been marked as a duplicate of this bug. ***
Comment 44 Jay Patel [:jay] 2005-06-27 16:01:39 PDT
Pav is putting together the necessary Trunk patches (from bug 284716 and any
resulting regressions) that need to land on the branches.  Those changes should
fix this problem and provide some performance enhancements as well.
Comment 45 Daniel Veditz [:dveditz] 2005-06-29 07:43:27 PDT
reopening to assign to Pav
Comment 46 Daniel Veditz [:dveditz] 2005-06-29 08:43:20 PDT
Re-closing fixed on the trunk. The fix (bug 284716) had regressions. This is a
good place to gather all the necessary patches in one place.
Comment 47 Jay Patel [:jay] 2005-06-29 16:29:49 PDT
After reading through bug 284716 and a few regression bugs mentioned there, it
looks like we at least want the following patches on the branches:

1. Bug 284716 (https://bugzilla.mozilla.org/attachment.cgi?id=176232)
2. Bug 284978 (either https://bugzilla.mozilla.org/attachment.cgi?id=176528
and/or a work in progress, which requires both
https://bugzilla.mozilla.org/attachment.cgi?id=182038 and the patch in bug 292051)

Not sure if anything in bug 205893 or bug 204374 is needed here...but might be
worth a look. 

If all we need are the 2 patches I found, let's try to get them in tonight so we
can have a day of regression testing.
Comment 48 Daniel Veditz [:dveditz] 2005-06-30 03:08:21 PDT
Fix from bug 284716 checked into 1.7 and aviary branches. First patch from bug
284978 regression fix checked in to branches.
Comment 49 Daniel Veditz [:dveditz] 2005-07-01 01:19:11 PDT
*** Bug 299355 has been marked as a duplicate of this bug. ***
Comment 50 Jay Patel [:jay] 2005-07-06 16:27:12 PDT
v.fixed on aviary with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9)
Gecko/20050706 Firefox/1.0.5
Comment 51 Daniel Veditz [:dveditz] 2005-07-07 00:41:09 PDT
may not be fixed... knoxvegas reports on IRC that he's still crashing with a
20050706 trunk firefox build.

http://www.tabwin.com/puss.html
http://www.jgiannotti.com/pwned
http://llama.i.am/
http://www.jgiannotti.com/pwn
Comment 52 Lloyd D Budd 2005-07-07 11:57:46 PDT
Tested at this time using link
http://home.tu-clausthal.de/~inmc/esg/iecrash.html (basic test case)
and on one of our "vulnerable" boxes :

Video Card        VIA/S3G UniChrome Pro IPG
Driver Version    6.144.10.144
Date                 6/8/2004

nightly/2005-07-06-20-trunk/firefox-1.0+.en-US.win32.installer.exe
results in bluescreen , but
nightly/2005-07-07-05-aviary1.0.1/firefox-1.0.5.en-US.win32.installer.exe
did NOT .  Firefox was unresponsive for a short period of time , but OS remained
functional .

Comment 53 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-07-10 13:24:37 PDT
*** Bug 300288 has been marked as a duplicate of this bug. ***
Comment 54 Pardal Freudenthal (:ShareBird) 2005-07-10 17:30:53 PDT
Two more sites that crash Windows XP SP2 with all patches using Firefox:

http://www.cheater4ever.de.vu/

http://www.hunger.hu/win.html 

I think it becomes really a serious issue since more and more sites are using it.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050710
Firefox/1.0+ ID:2005071006
Comment 55 Aaron Slunt 2005-07-10 18:16:10 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050710
Firefox/1.0+ ID:2005071006

Using http://www.hunger.hu/win.html

Windows gave me a stop error for my video card.

Of course I have all the latest crap on it, so I'm not even going to go into
that, albeit my vid card is only 16 megs, it doesn't crash on other links like
comment 51 (but I haven't tried the first link comment 54)

I'm not testing any other links. The stop error says my video card goes into an
endless loop.

9999999 squared pixels should not be parsed: There should most definitely be a
limit set. Make a default setting of 10000 pixels, and if a user needs to change
it, then they can change it at their own risk.
Comment 56 IU 2005-07-10 20:11:59 PDT
Here is my experience with this bug. Maybe this will give some clues (Windows
XP, SP2; P3 933 MHz; 512 MB RAM; GeForce2 MX):

1. Deer Park Alpha 1, June 19 Trunk
a) NO CRASH whatsoever for above posted URLs *EXCEPT*
http://home.tu-clausthal.de/~inmc/esg/iecrash.html with many extensions. Tested
this bug back in June and tested again today.

2. Deer Park Alpha 2, July 10 Trunk
a) Safe Mode: NO CRASH
b) Normal Mode: CRASH - (with clean profile or profile having many extensions

3. Internet Explorer
a) CRASH
Comment 57 Ph3rny 2005-07-11 11:45:45 PDT
(In reply to comment #56)
> Here is my experience with this bug. Maybe this will give some clues (Windows
> XP, SP2; P3 933 MHz; 512 MB RAM; GeForce2 MX):
> 
> 1. Deer Park Alpha 1, June 19 Trunk
> a) NO CRASH whatsoever for above posted URLs *EXCEPT*
> http://home.tu-clausthal.de/~inmc/esg/iecrash.html with many extensions. Tested
> this bug back in June and tested again today.
> 
> 2. Deer Park Alpha 2, July 10 Trunk
> a) Safe Mode: NO CRASH
> b) Normal Mode: CRASH - (with clean profile or profile having many extensions
> 
> 3. Internet Explorer
> a) CRASH


while testing did u restart ur comp between testings?

if not the results may be askew.

just sayin...
Comment 58 IU 2005-07-11 11:59:24 PDT
> while testing did u restart ur comp between testings?
>
> if not the results may be askew.
> 

Not Likely.  Hightly and consistently reproducible.  Order of testing does not
matter.  Each one of those individual tests has been performed at least once (as
the first test) after a restart.
Comment 59 Jay Patel [:jay] 2005-07-11 16:31:14 PDT
Once again, I am not crashing at any of the URLs mentioned in the past 7-8
comments.  Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9)
Gecko/20050709 Firefox/1.0.5 (and I have SP2 installed)
Comment 60 Frank Wein [:mcsmurf] 2005-07-12 06:35:57 PDT
*** Bug 300480 has been marked as a duplicate of this bug. ***
Comment 61 William Bumgarner [:zsinj] 2005-07-12 09:12:09 PDT
*** Bug 300461 has been marked as a duplicate of this bug. ***
Comment 62 Peter B 2005-07-12 11:43:02 PDT
Don't know if you know this or not but it seems that StretchBlt(...) is causing
the BSOD. The graphic card is trying to stretch that image to 9999999, causing
watchdog to think that the device driver is spinning in an infinite loop.
Resulting in a bugcheck...


debug trace:

THREAD_STUCK_IN_DEVICE_DRIVER (ea)

Debugging Details:
------------------

FAULTING_THREAD:  89261678

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_FAULT

BUGCHECK_STR:  0xEA

LAST_CONTROL_TRANSFER:  from 8080c9ce to 808047f3

STACK_TEXT:  
f752ffc0 8080c9ce f78bab40 f78bab70 00000000 nt!KiUnlockDispatcherDatabase+0x77
f752ffd4 f77dfa67 f78bab94 00000000 00000000 nt!KeSetEvent+0x74
f75302c8 80819282 f78bab40 f7530314 f7530308 watchdog!WatchdogKernelApc+0x13b
f7530318 80a17c35 00000000 00000000 f7530330 nt!KiDeliverApc+0xb3
f7530318 bf95d2c2 00000000 00000000 f7530330 hal!HalpApcInterrupt+0xc5
f75303bc bf85e9f3 008325d9 0391e233 0391d5f4 win32k!pxrlStrRead24+0x7d
f7530610 bf89e1d4 f7530574 00000000 00000196 win32k!EngStretchBlt+0xb1b
f75306b0 bf89dfc5 e18b1e90 e1687e90 00000000 win32k!EngStretchBltROP+0x3a5
f753078c bf846fc4 00000000 00000000 bf89e146 win32k!BLTRECORD::bStretch+0x41b
f75308c0 bf835c0c 01010057 0000000c 00000011 win32k!GreStretchBltInternal+0x632
f75308fc 808077ec 01010057 0000000c 00000011 win32k!GreStretchBlt+0x30
f75308fc 7c90eb94 01010057 0000000c 00000011 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
031eb2bc 00000000 00000000 00000000 00000000 0x7c90eb94

Comment 63 cacheoverflow 2005-07-12 12:25:02 PDT
behavior has improved on recent builds, many of the rogue sites are no longer
crashing deer park latest trunk 20050712 - however, this one particular site
uses a variant that is still crashing Firefox a2 badly.

This is the really troublesome site:
http://www.hunger.hu/win.html

if it doesn't crash your system the first time, try reloading that same site 3
or 4 times.
Comment 64 Peter B 2005-07-12 15:55:15 PDT
(In reply to comment #62)

Wrong function in my post.. Should be StretchDIBits(...) whats causing the
bugchecks.
Ignore that stack trace, that one is from IE...
Comment 65 Pardal Freudenthal (:ShareBird) 2005-07-13 11:03:15 PDT
Since this still occurs on the trunks, isn't it the case to reopen this bug?

A discussion about this issue was started on MozillaZine:

http://forums.mozillazine.org/viewtopic.php?t=291127
Comment 66 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-07-13 12:50:02 PDT
*** Bug 300665 has been marked as a duplicate of this bug. ***
Comment 67 Peter B 2005-07-13 21:30:31 PDT
Quick hack to fix this:

--- D:\CVS\mozilla\gfx\src\windows\nsImageWin.cpp	Thu Jul 14 04:22:12 2005 UTC
+++ D:\CVS\mozilla\gfx\src\windows\nsImageWin.cpp	Thu Jul 14 04:26:12 2005 UTC
@@ -469,6 +469,14 @@
   if (0 == aSWidth || 0 == aDWidth || 0 == aSHeight || 0 == aDHeight)
     return NS_OK;
 
+
+  // Hack: limit the amount we can stretch an image.
+  if ((aSWidth*4) < aDWidth)
+     aDWidth = aSWidth*4;
+  if ((aSHeight*4) < aDHeight)
+    aDHeight = aSHeight*4;
+
+
   if (mDecodedX2 < mDecodedX1 || mDecodedY2 < mDecodedY1)
     return NS_OK;
 
Comment 68 Peter B 2005-07-14 21:01:06 PDT
Hmm, that wasn't a very good hack..
This is probably better:

+  if ((aDWidth > 0xFFFF) || (aDHeight > 0xFFFF))  // 64k
+    return NS_ERROR_FAILURE;

Comment 69 Asa Dotzler [:asa] 2005-07-20 14:58:30 PDT
dbaron, can you help us figure out a reasonable size to clamp this down to avoid
the crash? 
Comment 70 Marcin Garski 2005-08-08 17:05:56 PDT
I've found a page that cause massive memory leak, probably it's a page with
oversized image, could somebody check it (if it isn't oversized image i'll fil
new bug)?

http://www.pmscollege.org/previous/hello.htm
Comment 71 Taral 2005-08-08 17:12:29 PDT
(In reply to comment #70)
> I've found a page that cause massive memory leak, probably it's a page with
> oversized image, could somebody check it (if it isn't oversized image i'll fil
> new bug)?

Nope, looks like a Javascript leaker. I think there's already something open
about this.
Comment 72 Lloyd D Budd 2005-08-08 17:15:04 PDT
Regarding , Comment #70 
leak or bloat ?  Anyway , looking @ the source of that page , I do not see a
relationship to this bug's issue .
Comment 73 IU 2005-08-08 17:25:01 PDT
It affects IE 6 too.  Thus, as others have pointed out, it is a javascript
issue.  The code looks like garbage.  I wonder if causing the leak was intentional.
Comment 74 Phil Ringnalda (:philor) 2005-09-08 22:16:43 PDT
*** Bug 307577 has been marked as a duplicate of this bug. ***
Comment 75 murray ward 2005-09-09 05:06:17 PDT
hi, just wondered if anyone on this thread had taken a look at:

https://bugzilla.mozilla.org/show_bug.cgi?id=307577

it's just been closed as a duplicate of this bug but seems to do with character 
encoding rather than oversized images.

the results are the same though - blue screen of death.

i was mostly wodering if anybody else had the same problem with the attached 
files (on the duplicate bug) or if it was just me. Be warned though, if you do 
have the same problem as me it will crash your system.
Comment 76 shutdown 2005-10-31 23:21:55 PST
*** Bug 314574 has been marked as a duplicate of this bug. ***
Comment 77 HyperHacker 2005-11-05 16:22:15 PST
I'm willing to bet the cause of this isn't the image dimensions directly, but rather the raw size of the stretched image. In my experience XP will crash if you run out of video memory very quickly (with low-capacity cards this can be seen by viewing a directory with hundreds of images in Thumbnail view). Thus it may help to have Firefox query how much video memory is available and not attempt to render any image which won't fit into memory. However, this needs to be implemented carefully as there is a race condition (available memory may decrease after it is measured but before the image renders).

Barring that, a simple workaround would be to implement a user pref specifying a limit on image size. Given the bit depth and dimensions, it should be possible to calculate the raw size of the stretched image, and refuse to render it if it exceeds this limit.
Comment 78 pavle 2006-09-20 23:34:15 PDT
I believe the problem starts with 5000px times 5000px original image dimensions.

Here is the original exploit URL.
http://ha.ckers.org/imagecrash.html
Comment 79 Phil Ringnalda (:philor) 2006-09-28 22:33:24 PDT
*** Bug 354783 has been marked as a duplicate of this bug. ***
Comment 80 Matthias Versen [:Matti] 2009-02-13 14:15:12 PST
This doesn't crash vista, is this fixed on winXP ?
Comment 81 Matthias Versen [:Matti] 2009-02-14 08:20:20 PST
got an email from "wild Bill" :
>yes, has been fixed on XP for quite some time :)

marking wfm
Comment 82 Bob Clary [:bc:] 2009-04-24 11:29:45 PDT
crash test landed
http://hg.mozilla.org/mozilla-central/rev/4e3d7a4d0b77

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