Closed Bug 441307 Opened 16 years ago Closed 13 years ago

Display corrupted with <HR WIDTH=999999999>

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
1.9.0 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: simos.bugzilla, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

testcase from second code
3.54 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; el-GR; rv:1.9) Gecko/2008061017 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; el-GR; rv:1.9) Gecko/2008061017 Firefox/3.0

In simple pages, <HR WIDTH="some big number..."> causes the rendering to get messed up. In more complex pages it can get Firefox 3 to crash.

During the investigation of this issue, a colleague sent an e-mail with sample code. When viewing the said e-mail, Firefox3 (x86_64) would crash all the time. In other versions of F3, the rendering would get severely corrupted.

Reproducible: Always

Steps to Reproduce:
This is to reproduce the corrupted rendering.

1. Create an HTML page with the following code

<HTML>
<BODY BGCOLOR="FFFFFF">
<HR WIDTH=143165425>
</BODY>
</HTML>

2. View page in Firefox 3.
3. Due to the long <HR>, there is a horizontal scrollbar.
Move to left and right using the mouse or keyboard. 
4. You can see that the rendered page gets corrupted.
Actual Results:  
The rendered page gets corrupted.

Expected Results:  
The page should render properly when you navigate left and right on the page.

The above code is rendered fine with Firefox 2. Therefore it appears to be a regression.

I have not tried to create a new custom invalid HTML mail and see whether F3 + GMail would crash. I submit the e-mail that produced the crash, when sent to a GMail account, and was viewed with F3 on Ubuntu 64-bit. On all other versions tests (Firefox 32-bit Linux, Firefox 32-bit Windows), the rendering would be messed up, but would not crash straight away.

It appears to be a architecture issue that makes it worse for 64-bit applications.

If you do not see the background color in the <BODY>, there appears to be no problem. It looks as if the 3D style+shadow of the <HR> messes up F3.

I have put this issue to Critical, since if it comes out publicly, it would be elemental to enhance the HTML code that would crash F3.
Due to the memory corruption, there is the possibility for remote exploit.

-------------------------------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
	<TITLE>Introduction to Linux</TITLE>
	<META NAME="GENERATOR" CONTENT="OpenOffice.org 2.0  (Linux)">
	<META NAME="CREATED" CONTENT="20070807;18534500">
	<META NAME="CHANGEDBY" CONTENT="Kostas Margaritis">
	<META NAME="CHANGED" CONTENT="20071002;10212600">
	<META NAME="KEYWORD" CONTENT="Linux">
	<META NAME="KEYWORD" CONTENT="Beginners">
	<META NAME="KEYWORD" CONTENT="linux">
	<META NAME="KEYWORD" CONTENT="start">
	<META NAME="KEYWORD" CONTENT="Getting started">
	<META NAME="KEYWORD" CONTENT="guide">
	<META NAME="KEYWORD" CONTENT="Guide">
	<META NAME="KEYWORD" CONTENT="Exercises">
	<META NAME="KEYWORD" CONTENT="exercises">
	<STYLE TYPE="text/css">
	<!--
		TD P { color: #000000 }
		H1 { color: #000000 }
		P { color: #000000 }
		H2 { color: #000000 }
		H3 { color: #000000 }
		DT { color: #000000 }
		DD { color: #000000 }
		PRE { color: #000000 }
		BLOCKQUOTE { color: #000000 }
		H4 { color: #000000 }
		TH P { color: #000000 }
		A:link { color: #0000ff }
		A:visited { color: #840084 }
	-->
	</STYLE>
</HEAD>
<BODY LANG="el-GR" TEXT="#000000" LINK="#0000ff" VLINK="#840084" BGCOLOR="#ffffff" DIR="LTR">
Line:5355
	<TABLE WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=2 BGCOLOR="#e0e0e0">
		<TR>
			<TD>
				<PRE>&lt;img alt=&quot;Garden with trees&quot; src=&quot;../images/garden.jpg&quot;&gt;</PRE>
			</TD>
		</TR>
	</TABLE>
	<LI><P>Ακόμη μια φορά σημειώστε τη διαφορά::</P>
</UL>
<DL>
	<DD>
	<TABLE WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=2 BGCOLOR="#e0e0e0">
		<TR>
			<TD>
				<PRE><FONT COLOR="#000000"><TT>theo:~&gt;</TT> <B>ls /mp3</B></FONT>
ls: /mp3: No such file or directory
theo:~&gt;ls mp3/
oriental/  pop/  sixties/
          </PRE>
			</TD>
		</TR>
	</TABLE>
<HR WIDTH=143165425 ALIGN=RIGHT>
Line :8776
	<TABLE WIDTH=100% BORDER=0 CELLPADDING=2 CELLSPACING=2>
		<TR>
			<TD WIDTH=25 VALIGN=TOP>
				<P ALIGN=CENTER><IMG SRC="intro-linux_files/note.gif" NAME="γραφικά40" ALT="Note" ALIGN=BOTTOM HSPACE=5 WIDTH=24 HEIGHT=24 BORDER=0></P>
			</TD>
			<TH>
				<P ALIGN=LEFT><B>Τα υφιστάμενα αρχεία
				παραμένουν αναλλοίωτα!</B></P>
			</TH>
		</TR>
		<TR>
			<TD>
				<P>&nbsp;</P>
			</TD>
			<TD VALIGN=TOP>
				<P ALIGN=LEFT>Τα αρχεία που μετακινούνται
				σε έναν κατάλογο SGID αλλά δημιουργήθηκαν
				κάπου αλλού διατηρούν τις αρχικές
				τους άδειες. Αυτό ίσως να δημιουργεί
				απορίες..</P>
			</TD>
		</TR>
	</TABLE>
<HR WIDTH=143165425 ALIGN=RIGHT>
</BODY>
</HTML>
-------------------------------------------------------------------------
No crash here on current windows trunk build.
The rendering corruptness is probably a known issue, moving to GFX->Thebes, I suspect it would be a crash in cairo.
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
I do see the messed up rendering, but I can't reproduce the crash,
using Firefox 3.0 (official i686 Linux build), or a local x86_64 debug
build on Kubuntu 8.04.  I suspect the crash on Linux is really an exit()
due to an XError, like bug 424333.

Simos, can you start Firefox in a Terminal window and let us know if
you see the "X Window System error" message?

Also, you said "... (Firefox 32-bit Linux, Firefox 32-bit Windows), the
rendering would be messed up, but would not crash straight away." --
does that mean you saw a crash on Windows too?
Keywords: crash, regression
Version: unspecified → 1.9.0 Branch
(In reply to comment #3)
> I do see the messed up rendering, but I can't reproduce the crash,
> using Firefox 3.0 (official i686 Linux build), or a local x86_64 debug
> build on Kubuntu 8.04.  I suspect the crash on Linux is really an exit()
> due to an XError, like bug 424333.
> 
> Simos, can you start Firefox in a Terminal window and let us know if
> you see the "X Window System error" message?
> 

There are the messages I get from the Ubuntu 8.06 (64-bit) Firefox:

===========================================
simos$ firefox -P bugzilla -no-remote -safe-mode
LoadPlugin: failed to initialize shared library /usr/lib/firefox-addons/plugins/libflashplayer.so [/usr/lib/firefox-addons/plugins/libflashplayer.so: wrong ELF class: ELFCLASS32]
** 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 0x6227f0: NP_GetMIMEDescription
GCJ PLUGIN: thread 0x6227f0: NP_GetMIMEDescription return
GCJ PLUGIN: thread 0x6227f0: NP_GetValue
GCJ PLUGIN: thread 0x6227f0: NP_GetValue: returning plugin name.
GCJ PLUGIN: thread 0x6227f0: NP_GetValue return
GCJ PLUGIN: thread 0x6227f0: NP_GetValue
GCJ PLUGIN: thread 0x6227f0: NP_GetValue: returning plugin description.
GCJ PLUGIN: thread 0x6227f0: NP_GetValue return
Floating exception                 [THIS IS PRINTED WHEN CRASH TAKES PLACE]

simos$  
(npviewer.bin:16045): Gtk-CRITICAL **: gtk_style_detach: assertion `style->attach_count > 0' failed
===========================================

Looking more carefully, there is some hint that the problem could be related to either GCJ or npviewer.bin. I do not think they are related.
If there is an way to disable plugins, please tell me to test again (Ubuntu 8.04).

I think the issue is to find where "Floating exception" comes from.

> Also, you said "... (Firefox 32-bit Linux, Firefox 32-bit Windows), the
> rendering would be messed up, but would not crash straight away." --
> does that mean you saw a crash on Windows too?
> 
I was quite unclear here. Sorry for this. I did not manage to make Firefox crash on a platform other than Linux/x86_64, in Ubuntu 8.04.
I did not try hard enough though to find a way to crash Firefox in other platforms.

These are messages from /var/log/messages:

[101765.141033] firefox[15772] trap divide error rip:7f35f96bd1d2 rsp:7fff07dbf620 error:0
[101805.840293] firefox[15879] trap divide error rip:7f2bf8c931d2 rsp:7fff07394c30 error:0
[101859.836565] firefox[15995] trap divide error rip:7f51c49571d2 rsp:7fffd30588e0 error:0
[102001.854903] firefox[16273] trap divide error rip:7f3ab7de51d2 rsp:7fffc64e4d60 error:0
[102077.572173] firefox[16418] trap divide error rip:7fcd3561d1d2 rsp:7fff43d204b0 error:0
[102457.135508] firefox[17124] trap divide error rip:7fbb05e851d2 rsp:7fff14585d10 error:0

(each line is a firefox crash).

Firefox crashes on me when I view the problematic e-mail in GMail. When loading a test page or something else with the mentioned code, Firefox does not crash.
I think this is the important issue.

If someone has firefox x86_64 (Linux?), then I can forward the specific e-mail to their gmail account, so that to try and reproduce.
(In reply to comment #4)
> Looking more carefully, there is some hint that the problem could be related
> to either GCJ or npviewer.bin. I do not think they are related.
> If there is an way to disable plugins, please tell me to test again (Ubuntu
> 8.04).

In Firefox 3 you should be able to disable plugins from the "Addons" dialog found on the Tools menu.
Whiteboard: [sg:needinfo]
Were you ever able to reproduce this crash with your plugins disabled?
Whiteboard: [sg:needinfo] → [sg:needinfo] Close by November 30 if no additional info
I tried again today to view the specific e-mail in GMail (that would crash Firefox, other pages would just mess up the display), with 

Mozilla/5.0 (X11; U; Linux x86_64; el-GR; rv:1.9.0.3) Gecko/2008101315 Ubuntu/8.10 (intrepid) Firefox/3.0.3
(found in Ubuntu 8.10)

and

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
(downloaded from mozilla.com)

Firefox did not crash in the problematic e-mail in any of the cases.
I would get a corrupted display of the page in Firefox, but no crash.
Thanks for the feedback. Since the crash is "worksforme" and on the assumption that you haven't filed a bug about the display issue, do you mind if I morph this one to cover that issue instead? We've already got a testcase here.

If this turns out to be a dupe we can close it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Summary: REGRESSION: Memory corruption/crash due to HTML code, <HR WIDTH=999999999> → Display corrupted with <HR WIDTH=999999999>
Whiteboard: [sg:needinfo] Close by November 30 if no additional info
Group: core-security
Thanks for taking this further.

I blogged about it in case there is further input,
http://simos.info/blog/archives/813
This bug no longer reproducible, marking fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
It's not known what fixed it, so marking worksforme.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: