Closed Bug 150339 Opened 18 years ago Closed 18 years ago

huge font crashes X Windows

Categories

(Core :: Internationalization, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: tom, Assigned: roland.mainz)

References

()

Details

(Keywords: crash, hang, intl)

Attachments

(2 files, 2 obsolete files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
BuildID:    2002041711

look at the URL above. this is what happens for me:

resolving... connecting... transferring data...
then X crashes. not just mozilla, X. error message of X: "bezierst this big not
yet supported"



Reproducible: Always
Steps to Reproduce:
1. start mozilla (doh)
2. enter into address bar: http://www.adeliesolutions.com/Projects/
3. wait about 3 sec

Actual Results:  X windows crashes

Expected Results:  loaded the page without crashing anything

I have filed a bug report to the XFree team as well. while this is obviously
caused by mozilla, X should handle the exception gracefully as well.
WFM, Moz1.0final on RH7.2 with WindowMaker.
confirming. 
linux, 2002060821
right after going to this page, machine started spapping like crazy 
(note, i have gig of ram) and then RandomTaskKiller killed X, blah, blah,
I had to reboot. I don't want to test it again :)
also tested with 1.0 now (build 2002052918), same result
Following to link http://www.adeliesolutions.com/Projects/ (I did not entered
it to address bar, but instead clicked it) did NOT crashed X or Mozilla 1.1a
(Build ID: 2002060804)  [hmm. however ... it seems that KDE is not able to open
any window now -- at least terminal emulator do not start -- so it seem to have
some resource shortage]


Comment to #4: After that test, KDE was unable to log out either and I was forced
to kill X server with Ctrl-Alt-Backspace -- after that X server was some
difficulties to restart. Mandrake 7.2 (with some updates -- mostly security.)
worksforme on WinXP :)
URL caused Mozilla to hang, crashed xfs for me and confused my windowmanager
(blackbox).  No X crash.
linux build 20020608 (trunk), RH73
Attached file testcase
note: "font-size: 166666px"
the behavior here is pretty similar to bug 149014 and is probably caused by the
same thing -- huge fonts.

however, I'm not crashing and my stack (while hanging) is completely different
(it's waiting for xfs to respond...)

what I'm seeing is probably INVALID (an xfs bug), but other's might be seeing
bug 149014, which (on Linux) might also be INVALID.
people that are crashing X: are you using xfs, or do you just have the fontpaths
specified in your XF86Config(-4) file?  If you are not using xfs, X is going to
crash instead of xfs (still INVALID).
does it happen with pref("font.FreeType2.enable", true); ?

(somebody, please test it, i don't want to crash again).
Tested this on a current CVS: X didnt' crash - xfs did.

Mozilla crashed after a 5 minute near full system freeze (P4/1.8).
X then got faster, but painted like in slow motion. Tried to restart it and
noticed the graphics driver got in some state where it didn't restart but
instead looped on deleting 16 agpgart related pages. Testing with a GF3/Ti200
card and Nvidia's 2880 drivers, built locally. (XFree86-4.2.0-6.62, kernel-2.4.18-4)

I am not running with any particular freetype settings in mozilla preferences.
But i do have tt fonts installed and enabled for xfs.

Regarding comment 8: No font seemed to be that size when i loaded the page on
XP. It's appearantly very easy to "DoS" linux with font sizes. There are several
older instances of this bug - I believe they usually get resolved as invalid?
I have the freetype pref enabled, but I'm not actually using any FreeType fonts.

the only bug I know of was bug 59355 which was that GDK would exit when the font
was too big.  That was fixed with an gdk error handler.  Most other font-too-big
bugs I found were marked dupes of that one.
I can reproduce the problem on an Ultra Sparc 10 running Solaris 8.

The Xserver freezes for a while then crashes.
comment 14 shows, that this problem isn't unique to XFree86 X server. So
shouldn't there be somewhere in mozilla checking for reasonable font size? There
is already possiblity to limit font size from below.
the error message about Beziers (comment 0) that Tom (and I) saw shows up in the
Type1 code for XFree86.  The error is followed by an abort.

Reassigning and to Internationalization since this seems to be a font issue and
Browser-general is probably not going to fix it.

==> Intl
Assignee: Matti → yokoyama
Component: Browser-General → Internationalization
QA Contact: imajes-qa → ruixu
Summary: crashes X Windows → huge font crashes X Windows
Keywords: crash
When I tried this, my X server quickly grew to over 1GB of RAM. The kernel
out-of-memory'd some javas, mozilla, some gnome-terminals, and a few other X
aps. That didn't bring it back. 

It managed to kill (from a remote machine through ssh) apache, postmaster (==
PostgreSQL ), and a few others before I managed to kill -9 XFree86. (Normal kill
without -9 did not work, maybe because of the thrashing).

This is a remote DoS attack, and a very effective one. The problem is probably
the following in the sitestyles.css file:

BODY   {font-size: 1666666px; font-family: Tahoma, Verdana, Arial, sans-serif} 

X11 runs with root priveleges. Mozilla doesn't. This might also be considered a
security issue with XFree86.

[btw we don't get a talkback report from this, and hang seems much more
appropriate for a keyword.]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang
Lets stop worrying about the different ways this can cause crashes, and start
talking about a solution.  The simplest idea is to put a (prefed probably) max
size on fonts; not a bad idea anyways.

We'll want this for 1.0.1.
Keywords: mozilla1.0.1
shanjian: It's a linus crasher. Please take a look.
Assignee: yokoyama → shanjian
Keywords: intl
QA Contact: ruixu → ylong
Problem confirmed on Ultra10 with Solaris 8 (4/02) and Mozilla 1.0rc3 (build
20020524)

X server crashes after ~3 seconds of loading the URL.
*** Bug 150849 has been marked as a duplicate of this bug. ***
This bug is not working, when I set Minimal font size in "Preferences" from
"None" to 12 or any other.
I'm using Linux Mandrake 8.2, XFree86 4.2.0.
More results:

Crashes xfs on RedHat 7.3/standard X 4.2.0 RPM install with build 2002052918
(1.0 release); does NOT crash Mozilla NOR X.

I restarted xfs just fine w/o any problems (thus far, anyway).

I also had the "minimum font size" set to 12 in
Edit->Preferences->Navigator->Fonts... maybe this is a workaround?
What about restricting the maximum font size to the maximum width/height (or 1/2
or 1/4) of the current screen ?
I want to add pref("browser.display.max_font_size", int) value (or other name)
into all.js (or unix.js).
User wants to override this value, user sets any value in user.js (or prefs.js).
No, let's not have a pref. Why on earth do we need a pref? If it's got no UI,
then all it does is clutter up the preferences file and mean that we have to
remember to check it. No one will _ever_ change the pref if we have one. I promise.

Let's just set a sensibly large maximum font size, and leave it at that.

Gerv
nothing happens, where's the joke?

Mozilla 1.0 of May 29 2002 and Beonex 0.8

XFree86 Version 4.1.0 / X Window System
(protocol Version 11, revision 0, vendor release 6510)

SuSE Linux (originally 6.4, now at least in part 7.3)

IceWM
I guess this doesn't happen if mozilla & X use raster fonts with `noscale' option.

also, different font servers can have different reaction. Some of them may have
checking for reasonable font size.
Attached patch patch (obsolete) — Splinter Review
This patch limits the size of fonts to twice the display height.  I've actually
wanted fonts bigger than the display at times, but limiting font size to twice
the display height seems reasonable.
The patch misses the Xlib gfx version... I'll file a new one...
Attachment #87422 - Flags: review+
Comment on attachment 87422 [details] [diff] [review]
patch

r=tor
Attached patch Patch for 2002-06-07-08-trunk (obsolete) — Splinter Review
Attachment #87422 - Attachment is obsolete: true
Requesting r=/sr= ...
Keywords: patch, review
Comment on attachment 87429 [details] [diff] [review]
Patch for 2002-06-07-08-trunk

sr=blizzard
Attachment #87429 - Flags: superreview+
xx@@@!!... I forgot to diff the gtk tree... here comes the patch that covers
both GTK+ gfx and Xlib gfx...

... sorry for the chaos... looks I need more coffee today... ;-(
Attachment #87429 - Attachment is obsolete: true
Comment on attachment 87432 [details] [diff] [review]
Patch for both GTK+ gfx and Xlib gfx

Carrying over the sr=roc+moz from the GTK+ gfx patch (attachment 87422 [details] [diff] [review]) and the
sr=blittard from the Xlib gfx patch (sr=blizzard) ...
Attachment #87432 - Flags: superreview+
Comment on attachment 87432 [details] [diff] [review]
Patch for both GTK+ gfx and Xlib gfx

r=tor
Attachment #87432 - Flags: review+
Taking bug myself...

----

Requesting a= for 1.0.1-branch...
Assignee: shanjian → Roland.Mainz
Keywords: approval
Target Milestone: --- → mozilla1.0.1
Tested in a Sun Ray 1 environment. Server running Solaris 8 + patches and Ray
server 1.2. It DoS'es the entire Ray software thus disbling all users sessions.
A restart of the utsvc (the Ray X services) killed the session running mozilla
and restored the other sessions. 

Mozilla was running on a linux box. I'm _not_ testing it with other mozillas.

NB! Sun users. Don't try this at work!
This sounds like a duplicate of bug 120238
this "bug" has been showing up in BugTrak as well, here's 
a recent post from Alan Cox:

Subject:  Re: Very large font size crashing X Font Server and Grounding Server to
To: "Federico Sevilla III" <jijo@free.net.ph>
Date: Thu, 13 Jun 2002 06:39:35 +0100 (BST)
CC: "BugTraq Mailing List" <bugtraq@securityfocus.com>, "Linux Kernel Mailing
List" <linux-kernel@vger.kernel.org>
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk> 

> check to prevent such large sizes from crashing X and/or the X Font
> Server, I'm alarmed by (1) the way the X font server allows itself to be
> crashed like this, and (2) the way the entire Linux kernel seems to have
> been unable to handle the situation. While having a central company or

So turn on the features to conrol it. Set rlimits on the xfs server and 
enable non overcommit (-ac kernel)

Alan
*** Bug 151616 has been marked as a duplicate of this bug. ***
This URL http://www.adeliesolutions.com/Projects/ does nothing with my Mozilla
and X. Probably file is changed to make it safe. 

URL http://mozillacrash.by.ru/a.html especially demonstrates this bug. URL
http://mozillacrash.by.ru/ demonstrates how user can protect Mozilla form this bug.
This bug is in the news, Mozilla is called a vector for DOS:

X-windows remote DoS with big fonts

http://www.theregister.co.uk/content/55/25689.html

I'm quite sure this is a dupe of bug 120238, but this one has the patches, so
the other will have to go...
*** Bug 120238 has been marked as a duplicate of this bug. ***
Just noting that bug 149014 and bug 149015 are both related to huge fonts, with
149014 being a crasher on Linux and Windows.  I will see if the proposed patch
here goes any way towards solving these other bugs.
tested a trunk build and it doesn't crash xfs.  isn't this FIXED (on trunk)?
Comment on attachment 87432 [details] [diff] [review]
Patch for both GTK+ gfx and Xlib gfx

Please land this on the 1.0.1 branch.  Once there, remove the
"mozilla1.0.1+" keyword, and add the "fixed1.0.1"
Attachment #87432 - Flags: approval+
Checked into the 1.0 branch.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
The URL seems to have changed, changing to the URL of the dupe.
I can not reproduce this hang on 06-19 1.0 branch build /Linux RH7.2 with URL:
http://www.mbnet.fi/hintaseuranta/kaupat.asp and the test case attached in this
bug, although the loading time takes a little longer than normal pages.

Mark as verified, please re-open if still see the same problem.
Status: RESOLVED → VERIFIED
*** Bug 115788 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.