Closed Bug 474305 Opened 11 years ago Closed 11 years ago

Crash: Corrupted image reliably crashes on 64-bit 1.9.0 branch (but not trunk)

Categories

(Core :: Graphics, defect)

1.9.0 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 424333

People

(Reporter: gareth.randall, Unassigned)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.5) Gecko/2008121622 Fedora/3.0.5-1.fc9 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.5) Gecko/2008121622 Fedora/3.0.5-1.fc9 Firefox/3.0.5

The attached image crashes the specified browser version reliably. The image was programatically generated and is corrupted, but I do not know the details of 

Note that it does not crash the very latest build: "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090119 Minefield/3.2a1pre"

I'm reporting this as a security issue, just in case it is exploitable. (I don't know your release schedule for 3.2, so the 3.0 branch may be around for some time.)

(Note that the image also crashes Apple's "Preview" app.)

Reproducible: Always

Steps to Reproduce:
1. Start Firefox.
2. Load file using: File, Open... -> Choose file (componentHistogram.png)
3. Firefox then crashes.
Actual Results:  
Crashes.

Expected Results:  
Displays image partly corrupted, or displays an error that image is corrupted.

Behaviour on MacOSX:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-GB; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
(Running on:  Mac OS X 10.4.11  Build 8S165)

Start Mozilla. Then load file using:
File, Open... -> Choose file (componentHistogram.png)

Result: Doesn't crash, and doesn't display image at all.

Starts off with border of image in "fit to screen" view, showing a broken image icon in top left corner.
When clicking on image, border goes to full size, but within border displays:

The image
"file:///(actual path and filename)"
cannot be displayed, because it contains errors.
If I try to browse for the PNG itself using File->Open, Firefox goes in to 100% CPU, but that's another bug. Consequently I've had to bzip2 the image in order to select it and upload it.
Component: General → GFX
Product: Firefox → Core
QA Contact: general → general
Actually, the steps to reproduce should be:

Steps to Reproduce:
1. Start Firefox.
2. Type local URL of file in to URL box: e.g. file:///whervercomponentHistogram.png
3. Press Enter to load.
4. Firefox then crashes.
This is worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6pre) Gecko/2009010606 GranParadiso/3.0.6pre

Do you have a breakpad id of the crash? Or a stacktrace?
I notice Gareth is on x86_64, which doesn't build with crash reporter, iirc.
Summary: Corrupted image reliably crashes current latest release (but not latest trunk) → Crash: Corrupted image reliably crashes on 64-bit 1.9.0 branch (but not trunk)
Version: unspecified → 1.9.0 Branch
This may help:

$ firefox -safe-mode
sh: acroread: command not found
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
** Message: GetValue variable 1 (1)
** Message: GetValue variable 2 (2)
GCJ PLUGIN: thread 0x1e543e0: NP_GetMIMEDescription
GCJ PLUGIN: thread 0x1e543e0: NP_GetMIMEDescription return
GCJ PLUGIN: thread 0x1e543e0: NP_GetValue
GCJ PLUGIN: thread 0x1e543e0: NP_GetValue: returning plugin name.
GCJ PLUGIN: thread 0x1e543e0: NP_GetValue return
GCJ PLUGIN: thread 0x1e543e0: NP_GetValue
GCJ PLUGIN: thread 0x1e543e0: NP_GetValue: returning plugin description.
GCJ PLUGIN: thread 0x1e543e0: NP_GetValue return
The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 26233 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.)
I have another example of an image that causes a crash. This one is called 
componentHistogram2.png (attached).

The output for this image is as follows:

$ firefox -safe-mode
The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 54606 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.)
cc'ng some graphics guys who may or may not be watching this component
The images are large: 570x59140 and 570x58120 which is probably the reason for the X error. I don't expect this to be exploitable as it looks like X is just giving us a BadAlloc error.
I was pretty sure we handled large images properly. Vlad?
The patch for this never made it into 1.9.0 I don't think; it should be fixed on 1.9.1 and trunk.  It's bug 424333.
That bug is WONTFIX on 1.9.0, so this one is WONTFIX. Sorry!

(Also opening up this bug, since it's a clear dupe.)
Group: core-security
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Resolution: WONTFIX → DUPLICATE
Duplicate of bug: 424333
Product: Core → Core Graveyard
Component: GFX → GFX: Thebes
Product: Core Graveyard → Core
QA Contact: general → thebes
You need to log in before you can comment on or make changes to this bug.