441210 - gdk_x_error BadAlloc abort when loading http://zoy.org/~sam/lol-firefox3.jpeg

Status: RESOLVED DUPLICATE of bug 424333

(Core :: Graphics, defect)

Description

[Carsten Book [:Tomcat]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1pre) Gecko/2008062009 Minefield/3.0.1pre

Steps to reproduce: (based on http://beranger.org/index.php?page=diary&2008/06/22/12/32/34-firefox-3-crashed-by-a-jpg)
-> Load http://zoy.org/~sam/lol-firefox3.jpeg
-> Firefox crash on Fedora 9

The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 19899 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
nsStringStats
 => mAllocCount:          20800
 => mReallocCount:         4146
 => mFreeCount:           12900  --  LEAKED 7900 !!!
 => mShareCount:          17786
 => mAdoptCount:           1706
 => mAdoptFreeCount:       1701  --  LEAKED 5 !!!
[Thread 0xb324bb90 (LWP 2650) exited]
[Thread 0xb3c4cb90 (LWP 2649) exited]
[Thread 0xb5470b90 (LWP 2647) exited]
[Thread 0xb6872b90 (LWP 2646) exited]
[Thread 0xb5e71b90 (LWP 2645) exited]
[Thread 0xb7319b90 (LWP 2642) exited]
[Thread 0xb7d1ab90 (LWP 2641) exited]

Program exited with code 01.
Missing separate debuginfos, use: debuginfo-install GConf2.i386 ORBit2.i386 alsa-lib.i386 atk.i386 audiofile.i386 avahi.i386 bug-buddy.i386 bzip2.i386 cairo.i386 dbus-glib.i386 dbus.i386 e2fsprogs.i386 elfutils.i386 esound.i386 expat.i386 fontconfig.i386 freetype.i386 gail.i386 gcc.i386 glib2.i386 glibc.i686 gnome-keyring.i386 gnome-vfs2.i386 gtk-nodoka-engine.i386 gtk2.i386 keyutils.i386 krb5.i386 libICE.i386 libSM.i386 libX11.i386 libXScrnSaver.i386 libXau.i386 libXcomposite.i386 libXcursor.i386 libXdmcp.i386 libXext.i386 libXfixes.i386 libXft.i386 libXi.i386 libXinerama.i386 libXrandr.i386 libXrender.i386 libXt.i386 libart_lgpl.i386 libbonobo.i386 libbonoboui.i386 libcap.i386 libcroco.i386 libgnome.i386 libgnomecanvas.i386 libgnomeui.i386 libgsf.i386 libjpeg.i386 libpng.i386 librsvg2.i386 libselinux.i386 libxcb.i386 libxml2.i386 openssl.i686 pango.i386 pixman.i386 popt.i386 zlib.i386
(gdb) backtrace 
no stack

Comment 1

[Justin Dolske [:Dolske]]

Attachment: lol-firefox3.jpeg

Comment 2

[Justin Dolske [:Dolske]]

Created an image in Gimp with the same size (32888x90). Works fine, so it's presumably not just the large dimension.

Imagemagick says:

$ identify lol-firefox3.jpeg 
lol-firefox3.jpeg JPEG 32888x90 32888x90+0+0 DirectClass 8-bit 4.19141kb 
identify: Corrupt JPEG data: premature end of data segment `lol-firefox3.jpeg'.
identify: Corrupt JPEG data: bad Huffman code `lol-firefox3.jpeg'.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

This is marked sec-sensitive based on Asa's email to security group, but in that email Asa mentioned that he's not sure if it represents an actual security risk. Can we get that evaluated? So far it looks like we get an abort, but do we get memory violations?

Comment 4

[Mats Palmgren (inactive)]

FWIW, bug 424333 fixes the "crash" (a call to exit() really) on Linux.

Comment 5

[Brendan Eich [:brendan]]

Mats: so this bug is not security-sensitive, right? Someone please open it if so.

/be

Comment 6

[Mats Palmgren (inactive)]

My only concern would be if the libjpeg code had a memory violation earlier
that didn't cause a crash.  Valgrind on x86_64 Linux and MallocDebug
on MacOSX doesn't complain so that seems unlikely.
So it's just a sg:dos on Linux, as far as I can tell.

Comment 7

[Brian Crowder]

The crash is documented on a public blog, we might as well open the bug.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm not sure I'm the right one to open this up, but I would agree with calls to do so.

I don't think sg:dos calls for blocking1.9.0.1, but definitely wanted. Can we get a hurry up on the reviews on bug 424333?

Comment 9

[Brandon Sterne (:bsterne)]

Security Focus issued an advisory on this issue:
http://www.securityfocus.com/bid/29984/discuss

There is another sample exploit here:
http://www.securityfocus.com/bid/29984/exploit

Comment 10

[Daniel Veditz [:dveditz]]

Vlad: please find an appropriate assignee for this one.

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It's corrupt, but the problem is the size in the valid header -- 32888x90 .  Same bug as 424333.