974825 - Firefox hangs on a specific PNG image

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Patrick Gerken]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/32.0.1700.102 Chrome/32.0.1700.102 Safari/537.36

Steps to reproduce:

Open a website.
Log in to the extranet.

---
To Debug the issue, I tried to load the page in safe mode and with a nightly browser. The problem exists in 27 and in nightly. It does not appear in 26. It happens on 27 on other peopls computer too.
I created a crash report which is here:
https://crash-stats.mozilla.com/report/index/f757b297-7961-4866-9f20-e6a982140220
I installed the debugging symbols and tried to run a backtrace in gdb. This is the output of the backtrace:
Program received signal SIGABRT, Aborted.
__lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135     ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) 
(gdb) backtrace
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007ffff7bc7192 in _L_lock_1142 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff7bc7110 in __GI___pthread_mutex_lock (mutex=0x7fffb3e527e8) at pthread_mutex_lock.c:104
#3  0x00007ffff69e3b19 in PR_Lock (lock=lock@entry=0x7fffb3e527e8)
    at /build/buildd/firefox-27.0+build1/./nsprpub/pr/src/pthreads/ptsynch.c:174
#4  0x00007ffff69e40cd in PR_EnterMonitor (mon=0x7fffb3e527e0)
    at /build/buildd/firefox-27.0+build1/./nsprpub/pr/src/pthreads/ptsynch.c:529
#5  0x00007ffff3182d53 in ReentrantMonitorAutoEnter (aReentrantMonitor=..., this=0x7fffffffc7c8)
    at ../../dist/include/mozilla/ReentrantMonitor.h:182
#6  mozilla::image::RasterImage::DecodeDoneWorker::Run (this=0x7fffb4ca65c0)
    at /build/buildd/firefox-27.0+build1/image/src/RasterImage.cpp:3456
#7  0x00007ffff3dc94a1 in nsThread::ProcessNextEvent (this=0x7ffff6c26ca0, mayWait=<optimized out>, 
    result=0x7fffffffc87f) at /build/buildd/firefox-27.0+build1/xpcom/threads/nsThread.cpp:617
#8  0x00007ffff3d9cc29 in NS_ProcessNextEvent (thread=<optimized out>, mayWait=mayWait@entry=false)
    at /build/buildd/firefox-27.0+build1/xpcom/glue/nsThreadUtils.cpp:251
#9  0x00007ffff39dde4c in mozilla::ipc::MessagePump::Run (this=0x7fffe967bf40, aDelegate=0x7fffe9667240)
    at /build/buildd/firefox-27.0+build1/ipc/glue/MessagePump.cpp:85
#10 0x00007ffff3e03891 in RunHandler (this=0x7fffe9667240)
    at /build/buildd/firefox-27.0+build1/ipc/chromium/src/base/message_loop.cc:213
#11 MessageLoop::Run (this=0x7fffe9667240)
    at /build/buildd/firefox-27.0+build1/ipc/chromium/src/base/message_loop.cc:187
#12 0x00007ffff3962041 in nsBaseAppShell::Run (this=0x7fffe0b14be0)
    at /build/buildd/firefox-27.0+build1/widget/xpwidgets/nsBaseAppShell.cpp:161
#13 0x00007ffff38231a5 in nsAppStartup::Run (this=0x7fffe0b16d30)
    at /build/buildd/firefox-27.0+build1/toolkit/components/startup/nsAppStartup.cpp:268
#14 0x00007ffff2f72fb5 in XREMain::XRE_mainRun (this=this@entry=0x7fffffffcaf0)
    at /build/buildd/firefox-27.0+build1/toolkit/xre/nsAppRunner.cpp:3976
#15 0x00007ffff2f73235 in XREMain::XRE_main (this=this@entry=0x7fffffffcaf0, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffdfe8, aAppData=aAppData@entry=0x7fffffffccf0)
    at /build/buildd/firefox-27.0+build1/toolkit/xre/nsAppRunner.cpp:4044
#16 0x00007ffff2f73491 in XRE_main (argc=1, argv=0x7fffffffdfe8, aAppData=0x7fffffffccf0, aFlags=<optimized out>)
    at /build/buildd/firefox-27.0+build1/toolkit/xre/nsAppRunner.cpp:4246
#17 0x00005555555582f3 in do_main (argc=argc@entry=1, argv=argv@entry=0x7fffffffdfe8, xreDirectory=0x7ffff6c2f780)
    at /build/buildd/firefox-27.0+build1/browser/app/nsBrowserApp.cpp:280
#18 0x0000555555557ccc in main (argc=1, argv=0x7fffffffdfe8)
    at /build/buildd/firefox-27.0+build1/browser/app/nsBrowserApp.cpp:640
(gdb) run

I downloaded the page and gradually removed javascript and css includes. The result was that indpendent on which includes I removed, the page loaded, but not reliable. Removing something like 5 resources the page loaded half of the time. More or less independent on which resources I removed. My js and css resources are concatenated but there are still 20-30 resources.
I'd love to provide more debug information but I am not sure, what else I could provide.


Actual results:

Firefox reports in the bottom left that it is loading resources.
After a while, it just darkens and does not react to user input any more.


Expected results:

The page should have loaded.

Comment 1

[Patrick Gerken]

I removed the linux flag, as it happens on windows too.

Comment 2

[Patrick Gerken]

We were finally able to track it down to actually a single image that seems to break the page loading.
I added the image to the URL field. Its a white png image. It seems to be good when opening it with gimp.

It breaks firefox 27 on windows and linux, it does not break firefox 26 and earlier.

Comment 3

[Mayank Bansal]

i can confirm that the png file hangs the browser, didbt crash though.

Comment 4

[Alice0775 White]

Stack on hang: bp-90afe792-0f2c-4e2f-a77a-b66c62140220

Regression window
Not Crash:
http://hg.mozilla.org/integration/mozilla-inbound/rev/3e359c0a0d7a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20130926092245
Crash:
http://hg.mozilla.org/integration/mozilla-inbound/rev/8b84e9b8e24d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20130926115747
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3e359c0a0d7a&tochange=8b84e9b8e24d

Regressed by:
8b84e9b8e24d	Glenn Randers-Pehrson — Bug 841734 - Update libpng to version 1.6.6. r=jmuizelaar

Comment 5

[Glenn Randers-Pehrson]

glenn.rp> pngcheck -v news*png
File: newsportlet_background.png (272 bytes)
  chunk IHDR at offset 0x0000c, length 13
    1 x 93 image, 8-bit palette, non-interlaced
  chunk tEXt at offset 0x00025, length 25, keyword: Software
  chunk PLTE at offset 0x0004a, length 81: 27 palette entries
  chunk tRNS at offset 0x000a7, length 1: 1 transparency entry
  chunk IDAT at offset 0x000b4, length 0
  CRC error in chunk IDAT (computed 35af061e, expected 78da6c87)
ERRORS DETECTED in newsportlet_background.png

Comment 6

[Glenn Randers-Pehrson]

It seems that libpng16 is not detecting end-of-file, and not bailing out on the bad CRC in the IDAT chunk.

Comment 7

[Steven Doerfler]

I'm seeing Firefox 27.0.1 lock up when it tries to open a certain png (encountered as a favicon on the site http://www.burghvivant.com originally). Windows 8.1, Firefox's hardware accelerator disabled, all plugins disabled, in Firefox's safe mode. I suspect it's the same bug. Firefox hangs even if I just use File Open to view the png. Various image editors (Paint.net, Irfanview) report it's an invalid png, but don't crash. I'll attach the png to this bug report.

Comment 8

[Steven Doerfler]

Attachment: favicon.png

An invalid png that makes Firefox 27 hang. See #7 for details.

Comment 9

[Dave Garrett]

Confirmed on Linux with Aurora by just viewing this bug because I have the BugzillaJS addon installed which shows previews of attachments inline. :/

Comment 10

[Glenn Randers-Pehrson]

Confirmed that the problem is in libpng's progressive reader.  The "rpng2-x" program, in libpng/contrib/gregbook, exhibits the behavior as well.  rpng2-x built with libpng-1.6.0beta17 exits with an error message quickly while rpng2-x built with libpng-1.6.0beta18 hangs.

Comment 11

[Glenn Randers-Pehrson]

I had the regression range in libpng-1.6 wrong.  It's libpng-1.6.0beta27 that works and libpng-1.6.0beta28 that hangs.  There is a tight loop that happens when a file is truncated.  I'm not sure how to fix it, though, because I don't know how to tell the difference (within libpng) between a truncated file and a file that's coming in slowly, such that the loop should spin for a while and then resume when more data arrives.

Comment 12

[Glenn Randers-Pehrson]

Testing a one-line fix to the libpng progressive reader now.  It was failing to update the process_mode when it recognizes the first IDAT chunk.

Comment 13

[Glenn Randers-Pehrson]

Attachment: v00 fix libpng16 hang with zero-length IDAT

Tested locally, needs try server.  Bug has been reported to CERT VRF#HRZ9LFD9

Comment 14

[Glenn Randers-Pehrson]

Attachment: v01 fix libpng16 hang with zero-length IDAT, no MOZCHANGES update

Don't revise the MOZCHANGES file, to avoid conflicts when applying the patch to prior mozilla releases.  The v00 patch can and should be applied to the head instead.

Comment 15

[Glenn Randers-Pehrson]

This bug is CERT VU#684412 and CVE-2014-0333.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Can we add a crashtest for this too? :)

Comment 17

[Glenn Randers-Pehrson]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #16)
> Can we add a crashtest for this too? :)
I'll make one.

Comment 18

[Glenn Randers-Pehrson]

Attachment: v02 fix libpng16 hang with zero-length IDAT

Fixes bit rot due to libpng-1.6.9 checkin.  This patch should work against earlier versions as well as against the tip.  Includes a crash test.  Needs a try server run.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Thanks, Glenn :)

https://tbpl.mozilla.org/?tree=Try&rev=45b7de81b959

Comment 20

[Glenn Randers-Pehrson]

Comment on attachment 8382508 [details] [diff] [review]
v02 fix libpng16 hang with zero-length IDAT

Try run is almost all green (two IOS builds failed for some other reason).  The new crash tests show up as expected in the "C" logs.

Comment 21

[Glenn Randers-Pehrson]

"IOS builds" -> "OS X builds"

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Yes, those all look fine. The G orange is a known-bad test that was disabled.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ad3b57404218

Comment 24

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/ad3b57404218

Comment 25

[Glenn Randers-Pehrson]

Comment on attachment 8382508 [details] [diff] [review]
v02 fix libpng16 hang with zero-length IDAT

[Approval Request Comment]
Regression caused by (bug #): 886499
User impact if declined: Browser can be caused to hang by a malformed PNG
Testing completed (on m-c, etc.): yes on m-c, using the included crash test
Risk to taking this patch (and alternatives if risky):DoS
String or IDL/UUID changes made by this patch: none

Comment 26

[Glenn Randers-Pehrson]

Filled out the form wrong: I don't know of a risk to taking the patch.  The DoS is the risk of *not* taking the patch.

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8382508 [details] [diff] [review]
v02 fix libpng16 hang with zero-length IDAT

I am approving the patch for aurora. I will leave Lukas decide for 28.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/b225712ef2ed

Comment 29

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 8382508 [details] [diff] [review]
v02 fix libpng16 hang with zero-length IDAT

We can take this to 28 (and tracking as such) since it's a regression from 27 and there's enough risk to *not* taking it.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/516f5599024d

Comment 31

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/516f5599024d