253782 - Extremely large transparent PNG images crash [@ gfxImageFrame::SetAlphaData ] nearly all versions of Firefox and Mozilla

Status: VERIFIED FIXED

(Core Graveyard :: Image: Painting, defect)

Description

[dj28]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

Very large transparent PNG images (about 31,000 inches wide and a height of 1
pixel) crash Firefox (0.9.2 and 0.9.1 have been confirmed) and Mozilla (1.7
confirmed) on Linux and Windows. Gecko gives the error "division by zero."

Reproducible: Always
Steps to Reproduce:
1. Load http://www.dj28.com/images/pagewidener.png
2. Browser will crash.

Actual Results:  
Firefox and Mozilla will completely crash. It has been confirmed on approx. 10
different machines, on Windows 2000, Windows XP, and Linux.

Expected Results:  
Gecko should have displayed the very wide transparent PNG image.

The bug works accross all themes and has been tested on Firefox 0.9.1 and 0.9.2
but may work on all previous versions. It has also been tested on Mozilla 1.7
with the same result. About 10 seperate machines have confirmed with the same
result: A 'division by zero' error and crash.

Comment 1

[Bill Mason]

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

Comment 2

[Jo Hermans]

bug 227357 or bug 100250 ?

Comment 3

[dj28]

Bug 100250 looks like it has been fixed. This appears to be a different one.(In
reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040707 Firefox/0.9.2
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040707 Firefox/0.9.2
> 
> Very large transparent PNG images (about 31,000 inches wide and a height of 1
> pixel) crash Firefox (0.9.2 and 0.9.1 have been confirmed) and Mozilla (1.7
> confirmed) on Linux and Windows. Gecko gives the error "division by zero."
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Load http://www.dj28.com/images/pagewidener.png
> 2. Browser will crash.
> 
> Actual Results:  
> Firefox and Mozilla will completely crash. It has been confirmed on approx. 10
> different machines, on Windows 2000, Windows XP, and Linux.
> 
> Expected Results:  
> Gecko should have displayed the very wide transparent PNG image.
> 
> The bug works accross all themes and has been tested on Firefox 0.9.1 and 0.9.2
> but may work on all previous versions. It has also been tested on Mozilla 1.7
> with the same result. About 10 seperate machines have confirmed with the same
> result: A 'division by zero' error and crash.

(In reply to comment #2)
> bug 227357 or bug 100250 ?

100250 looks like it has been fixed. This appers to be a different one if I'm
not mistaken.

Comment 4

[Alessio]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040707 Firefox/0.9.2
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040707 Firefox/0.9.2
> 
> Very large transparent PNG images (about 31,000 inches wide and a height of 1
> pixel) crash Firefox (0.9.2 and 0.9.1 have been confirmed) and Mozilla (1.7
> confirmed) on Linux and Windows. Gecko gives the error "division by zero."

I confirm this crash on my Mozilla 1.7/Windows xp pro
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
Talkback Id: TB450501H

Comment 5

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

I see this with the 2004-07-30-90 Windows XP seamonkey build, too:

gfxImageFrame::SetAlphaData 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/shared/gfxImageFrame.cpp,
line 387]
row_callback 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp,
line 460]
MOZ_PNG_push_have_row 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libimg/png/pngpread.c,
line 1512]
MOZ_PNG_push_proc_row 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libimg/png/pngpread.c,
line 947]
MOZ_PNG_proc_IDAT_data 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libimg/png/pngpread.c,
line 740]
MOZ_PNG_push_read_IDAT 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libimg/png/pngpread.c,
line 696]
MOZ_PNG_proc_some_data 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libimg/png/pngpread.c,
line 94]
MOZ_PNG_process_data 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libimg/png/pngpread.c,
line 33]
ReadDataOut 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp,
line 161]
nsInputStreamTee::WriteSegmentFun 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/io/nsInputStreamTee.cpp,
line 103]
nsPipeInputStream::ReadSegments 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/io/nsPipe3.cpp,
line 764]
nsInputStreamTee::ReadSegments 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/io/nsInputStreamTee.cpp,
line 157]
nsPNGDecoder::WriteFrom 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp,
line 176]
imgRequest::OnDataAvailable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/src/imgRequest.cpp,
line 829]
ProxyListener::OnDataAvailable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/libpr0n/src/imgLoader.cpp,
line 879]
nsMediaDocumentStreamListener::OnDataAvailable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/document/src/nsMediaDocument.cpp,
line 118]
nsDocumentOpenInfo::OnDataAvailable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/uriloader/base/nsURILoader.cpp,
line 344]
nsStreamListenerTee::OnDataAvailable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsStreamListenerTee.cpp,
line 98]
nsHttpChannel::OnDataAvailable 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,
line 3722]
nsInputStreamPump::OnStateTransfer 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 438]
nsInputStreamPump::OnInputStreamReady 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsInputStreamPump.cpp,
line 339]
nsInputStreamReadyEvent::EventHandler 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/io/nsStreamUtils.cpp,
line 119]
PL_HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 693]
PL_ProcessPendingEvents 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 631]
_md_EventReceiverProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 1434]
USER32.dll + 0x3d79 (0x77d43d79)
USER32.dll + 0x3ddf (0x77d43ddf)
nsAppShellService::Run 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 489]
main1 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1331]
main 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1801]
WinMain 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/bootstrap/nsAppRunner.cpp,
line 1827]
WinMainCRTStartup()
kernel32.dll + 0x214c7 (0x77e814c7)

Comment 6

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

Need to move this out of Browser-General.

-> gfx.

Comment 7

[Bill Mason]

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

Comment 8

[Adam Hauner]

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

Comment 9

[Adam Hauner]

Rene Pronk in duped bug 253894 wrote:

It crashes in gfxImageFrame::SetAlphaData, line 386 because row_stride is zero.

383 #if defined(XP_WIN) || defined(XP_OS2)
384   // Adjust: We need offset to be top-down rows & LTR within each row
385   //    On win32 & os/2, it's passed in as bottom-up rows & LTR within each row
386   PRUint32 yOffset = ((PRUint32)(aOffset / row_stride)) * row_stride;
387   offset = ((mSize.height - 1) * row_stride) - yOffset + (aOffset % row_stride);
388 #else
389   offset = aOffset;
390 #endif

The first similar talkback stack dates from 2004-07-30 14:09:04

Comment 10

[Rene Pronk]

I took a look at the testcase in duped bug 253894
(http://www.hulver.com/scoop/story/2004/7/23/195343/919) and before it crashes,
it asserts in gfxImageFrame.cpp in line 323 because abpr is 0.

318   PRUint32 bpr, abpr;
319   decoder->mFrame->GetImageBytesPerRow(&bpr);
320   decoder->mFrame->GetAlphaBytesPerRow(&abpr);
321   decoder->colorLine = (PRUint8 *)nsMemory::Alloc(bpr);
322   if (channels > 3)
323     decoder->alphaLine = (PRUint8 *)nsMemory::Alloc(abpr);

I must say I don't know much about the PNG specs but the PNG decoder says the
image has 4 channels which sounds like a RGBA pattern to me but also says that
the image's AlphaBytesPerRow is 0. I'm wondering if this is valid. (not that we
should crash on it if it isn't of course) If it isn't valid perhaps we should
just not display the image or set its alpha layer to opaque.

Comment 11

[tor]

Attachment: limit image dimensions to less than 32767 on gtk

Comment 12

[tor]

Attachment: stop overflow on windows

Comment 13

[tor]

Checked both patches in on trunk.

Comment 14

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

'tha' alpha?  is that an acronym?

Comment 15

[Mike Kaply [:mkaply]]

Comment on attachment 154917 [details] [diff] [review]
limit image dimensions to less than 32767 on gtk

a=mkaply for all

Comment 16

[Mike Kaply [:mkaply]]

Comment on attachment 154990 [details] [diff] [review]
stop overflow on windows

a=mkaply for all

Comment 17

[tor]

Checked in on MOZILLA_1_4_BRANCH, MOZILLA_1_7_BRANCH, AVIARY_1_0_20040515_BRANCH.

Comment 18

[[e-mail]]

Comment on attachment 154990 [details] [diff] [review]
stop overflow on windows

8, 8, 32, 8: nice alignment ;-)

Comment 19

[Adam Hauner]

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

Comment 20

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

Verified FIXED on Windows XP using build 2004-08-03.

I'll let those on Linux chime in with their results before this bug is marked
verified.

Comment 21

[logan]

Same here on the 8/3 linux build.

Comment 22

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

Verified FIXED, then.

Comment 23

[Daniel Veditz [:dveditz]]

Is there more here than a crash that could be used as a DOS attack? This was
pushed into the 1.7.2 release which otherwise contained only security fixes, I
wanted to make sure I wasn't missing something that needed to be listed on the
vulnerabilities page.

Comment 24

[Mickey Stein]

I noted this gconfd segfault (GConf2-2.7.90-1) on FC3T1 running .9+ branch build
of firefox after this was checked in. Since this is the only checkin I saw
dealing with anything even close(crashes in a height routine), I was wondering
if this might be related? 

I used gdb to attach to gconfd (which runs for ~20 minutes or so before the
crash) and got this backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1291)]
0x4014ed03 in g_node_max_height () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0x4014ed03 in g_node_max_height () from /usr/lib/libglib-2.0.so.0
#1  0x4014ed18 in g_node_max_height () from /usr/lib/libglib-2.0.so.0
#2  0x4014f175 in g_node_traverse () from /usr/lib/libglib-2.0.so.0
#3  0x40044773 in gconf_listeners_remove_if (listeners=0x80614f0,
    predicate=0x3, user_data=0x3) at gconf-listeners.c:810
#4  0x0804bd2a in gconf_database_drop_dead_listeners (db=0x3)
    at gconf-database.c:923
#5  0x08051d7d in periodic_cleanup_timeout (data=0x0) at gconfd.c:1017
#6  0x40147078 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
#7  0x401444cb in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#8  0x40145f52 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#9  0x401461ff in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#10 0x08050baf in main (argc=2, argv=0x3) at gconfd.c:869

If you'd rather I put this on as a new bugzilla entry, no problem. I can run
older versions of FF without this GConf2 version crashing, as well as TB.