Closed Bug 289864 (imageBSOD) Opened 19 years ago Closed 15 years ago

Page crashes system (blue screen) with oversized image

Categories

(Core Graveyard :: Image: Painting, defect)

Product:
Core Graveyard
Component:
Image: Painting
Version:
1.7 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: taralx, Unassigned)

References

(
URL
)

Details

(Keywords: crash, fixed-aviary1.0.5, fixed1.7.9, Whiteboard: [sg:dos] system crash)

Attachments

(7 files)

WARNING!! BLUE SCREEN!! testcase
83.61 KB, text/plain
Details
image for testcase
41.20 KB, image/jpeg
Details
simplified testcase
100 bytes, text/html
Details
Patch to improve robustness in the face of erroneous user supplied data
855 bytes, patch
Details | Diff | Splinter Review
Patch to improve robustness in the face of erroneous user supplied data
791 bytes, patch
Details | Diff | Splinter Review
Patch to improve robustness in the face of erroneous user supplied data
901 bytes, patch
Details | Diff | Splinter Review
alt testcase : WinXP html using large IMG dimensions via CSS
374 bytes, text/html
Details 
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:
I filed this because firefox should probably filter really huge images like
this, especially if they can be used to exploit OS-level bugs.
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 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Keywords: crash
Resolution: --- → DUPLICATE
Whiteboard: [sg:dupe 214146]
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.
URL: http://www.livejournal.com/community/... → http://jameth.whatthefuck.com/apr2005...
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
This now has been posted to Bugtraq.
URL: http://jameth.whatthefuck.com/apr2005... → http://www.livejournal.com/users/deep...
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.
Group: security
Status: UNCONFIRMED → NEW
Ever confirmed: true
blocking-aviary1.0.4?
Flags: blocking-aviary1.0.4?
Note updated URL. Not sure how long it'll last, since the previous incarnation
got killed.
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
(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.
Whiteboard: [sg:dupe 214146] → [sg:fix]
the test image that was in the bug is now gone ;/  can someone find another
version that breaks?
Is bug 166862 related? (found by njyoder)
(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
Attached image image for testcase — 

    
    

    
  

      
      
      
      

        Attached file
          
        simplified testcase
        — 
      

    


  
Simplified testcase from bug 295383

    
    

    
  
*** Bug 295383 has been marked as a duplicate of this bug. ***

    
    

    
  
This appears OK on the Deer Park Alpha, could it be fixed by the large-value
colspan/rowspan bug 141818?

    
    

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

    
    

    
  


  
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

        Attachment #184497 -
        Flags: review+

    
    

    
  


  
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.

    
  

        Attachment #184497 -
        Flags: review+ → review?

    
  

        Attachment #184498 -
        Flags: review?

    
    

    
  


  
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.

    
  

        Attachment #184499 -
        Flags: review?

    
    

    
  
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.



    
    

    
  
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. 

    
    

    
  
Another site using this trick: http://winboot.mine.nu/

Opera does not crash.

    
    

    
  
*** Bug 297554 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 297695 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 297701 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 297879 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 298034 has been marked as a duplicate of this bug. ***
Alias: imageBSOD

    
    

    
  
*** Bug 298080 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 298147 has been marked as a duplicate of this bug. ***

    
    

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

    
    

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

    
    

    
  
(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.
Component: Security → Image: GFX
Depends on: 284716
Flags: review?
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5+
Product: Firefox → Core
Version: unspecified → 1.0 Branch

    
    

    
  
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.
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Flags: blocking-aviary1.0.5+ → blocking-aviary1.0.5-
Resolution: --- → FIXED
Flags: blocking1.7.9-

    
  
Version: 1.0 Branch → 1.7 Branch

    
    

    
  
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 .

    
    

    
  
(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.
Flags: blocking1.7.9?
Flags: blocking1.7.9-
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5-

    
    

    
  
Setting blocking1.7.9 and blocking-aviary1.0.5 per 1.0.5 meeting.
Flags: blocking1.7.9?
Flags: blocking1.7.9+
Flags: blocking-aviary1.0.5?
Flags: blocking-aviary1.0.5+

    
    

    
  
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 ?

    
    

    
  


  
Alternate testcase : WinXP html using large IMG dimensions via CSS

    
    

    
  
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. 

    
    

    
  
*** Bug 298641 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 298660 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 298781 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
reopening to assign to Pav
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: dveditz → pavlov
Status: REOPENED → NEW

    
    

    
  
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.
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED

    
    

    
  
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.

    
    

    
  
Fix from bug 284716 checked into 1.7 and aviary branches. First patch from bug
284978 regression fix checked in to branches.
Depends on: 284978
Keywords: fixed-aviary1.0.5, 
          
            fixed1.7.9

    
    

    
  
*** Bug 299355 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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 .



    
    

    
  
*** Bug 300288 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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

    
    

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


    
    

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


    
    

    
  
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)

    
    

    
  
*** Bug 300480 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 300461 has been marked as a duplicate of this bug. ***

    
    

    
  
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



    
    

    
  
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.

    
  
Flags: blocking1.9a1?
Flags: blocking1.8b4?
Flags: blocking1.8b3?

    
  
Flags: blocking1.9a1?

    
    

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

    
  
Flags: blocking1.8b4?
Flags: blocking1.8b3?

    
    

    
  
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

    
    

    
  
*** Bug 300665 has been marked as a duplicate of this bug. ***

    
    

    
  
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;
 


    
    

    
  
Hmm, that wasn't a very good hack..
This is probably better:

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



    
  
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
  
Flags: blocking1.8b4?

    
    

    
  
dbaron, can you help us figure out a reasonable size to clamp this down to avoid
the crash? 
Flags: blocking1.8b4? → blocking1.8b4+

    
    

    
  
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

    
    

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

    
    

    
  
Regarding , Comment #70 
leak or bloat ?  Anyway , looking @ the source of that page , I do not see a
relationship to this bug's issue .


    
    

    
  
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.

Flags: blocking1.8b4+ → blocking1.8b4-

    
    

    
  
*** Bug 307577 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 314574 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
  
Whiteboard: [sg:fix] → [sg:dos] system crash
Flags: testcase+

    
    

    
  
I believe the problem starts with 5000px times 5000px original image dimensions.

Here is the original exploit URL.
http://ha.ckers.org/imagecrash.html

    
    

    
  
*** Bug 354783 has been marked as a duplicate of this bug. ***
Flags: in-testsuite+ → in-testsuite?

    
  
Assignee: pavlov → nobody
Status: REOPENED → NEW
QA Contact: firefox → image.gfx

    
    

    
  
This doesn't crash vista, is this fixed on winXP ?

    
    

    
  
got an email from "wild Bill" :
>yes, has been fixed on XP for quite some time :)

marking wfm
Status: NEW → RESOLVED
Closed: 19 years ago → 15 years ago
Resolution: --- → WORKSFORME

    
    

    
  
crash test landed
http://hg.mozilla.org/mozilla-central/rev/4e3d7a4d0b77
Flags: in-testsuite? → in-testsuite+

    
  
Product: Core → Core Graveyard

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: