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

RESOLVED DUPLICATE of bug 424333

Status

()

RESOLVED DUPLICATE of bug 424333
11 years ago
8 years ago

People

(Reporter: cbook, Assigned: vlad)

Tracking

({testcase})

1.9.0 Branch
x86
Linux
testcase
Points:
---
Bug Flags:
blocking1.9.0.1 -
blocking1.9.0.5 -
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:nse dos] fixed by bug 424333?, URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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
Created attachment 326212 [details]
lol-firefox3.jpeg
(Reporter)

Updated

11 years ago
Severity: normal → critical
Keywords: crash, testcase
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'.

Severity: critical → normal

Updated

11 years ago
Flags: blocking1.9.0.1?

Updated

11 years ago
Component: General → GFX: Gtk
Keywords: crash
QA Contact: general → gtk
Summary: Firefox crash when loading http://zoy.org/~sam/lol-firefox3.jpeg → gdk_x_error BadAlloc abort when loading http://zoy.org/~sam/lol-firefox3.jpeg
Whiteboard: DUPEME
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?
FWIW, bug 424333 fixes the "crash" (a call to exit() really) on Linux.
Depends on: 424333
Mats: so this bug is not security-sensitive, right? Someone please open it if so.

/be
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.
Whiteboard: DUPEME → [sg:dos]

Comment 7

11 years ago
The crash is documented on a public blog, we might as well open the bug.
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?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Whiteboard: [sg:dos] → [sg:dos] fixed by bug 424333?
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
Flags: blocking1.9.0.3?
Whiteboard: [sg:dos] fixed by bug 424333? → [sg:nse dos] fixed by bug 424333?
Group: core-security
Flags: blocking1.9.0.3? → blocking1.9.0.3+
Flags: blocking1.9.0.4+ → blocking1.9.0.5+
Vlad: please find an appropriate assignee for this one.
Assignee: nobody → vladimir
Flags: blocking1.9.1?
It's corrupt, but the problem is the size in the valid header -- 32888x90 .  Same bug as 424333.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 424333
Flags: blocking1.9.0.5+ → blocking1.9.0.5-
Flags: blocking1.9.1?
Product: Core → Core Graveyard
Component: GFX: Gtk → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: gtk → thebes
You need to log in before you can comment on or make changes to this bug.