150339 - huge font crashes X Windows

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Tom]

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.

Comment 1

[Garth Wallace]

WFM, Moz1.0final on RH7.2 with WindowMaker.

Comment 2

[nick slussar]

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 :)

Comment 3

[Tom]

also tested with 1.0 now (build 2002052918), same result

Comment 4

[Kari Hurtta]

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 5

[Kari Hurtta]

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.)

Comment 6

[Manoj]

worksforme on WinXP :)

Comment 7

[Andrew Schultz]

URL caused Mozilla to hang, crashed xfs for me and confused my windowmanager
(blackbox).  No X crash.
linux build 20020608 (trunk), RH73

Comment 8

[Andrew Schultz]

Attachment: testcase

note: "font-size: 166666px"

Comment 9

[Andrew Schultz]

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.

Comment 10

[Andrew Schultz]

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).

Comment 11

[nick slussar]

does it happen with pref("font.FreeType2.enable", true); ?

(somebody, please test it, i don't want to crash again).

Comment 12

[R.K.Aa.]

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?

Comment 13

[Andrew Schultz]

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.

Comment 14

[Renaud Manus]

I can reproduce the problem on an Ultra Sparc 10 running Solaris 8.

The Xserver freezes for a while then crashes.

Comment 15

[nick slussar]

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.

Comment 16

[Andrew Schultz]

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

Comment 17

[Anthony DeRobertis]

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.]

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 19

[Roy Yokoyama]

shanjian: It's a linus crasher. Please take a look.

Comment 20

[Jeff Giacobbe]

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.

Comment 21

[Olivier Cahagne]

*** Bug 150849 has been marked as a duplicate of this bug. ***

Comment 22

[Nikola Antonov]

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.

Comment 23

[J. Paul Reed [:preed]]

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?

Comment 24

[Roland Mainz]

What about restricting the maximum font size to the maximum width/height (or 1/2
or 1/4) of the current screen ?

Comment 25

[KONDOU, Kazuhiro]

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).

Comment 26

[Gervase Markham [:gerv]]

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

Comment 27

[Christian Schneider]

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

Comment 28

[nick slussar]

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.

Comment 29

[Christopher Blizzard (:blizzard)]

Attachment: patch

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.

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 87422 [details] [diff] [review]
patch

sr=roc+moz

Comment 31

[Roland Mainz]

The patch misses the Xlib gfx version... I'll file a new one...

Comment 32

[tor]

Comment on attachment 87422 [details] [diff] [review]
patch

r=tor

Comment 33

[Roland Mainz]

Attachment: Patch for 2002-06-07-08-trunk

Comment 34

[Roland Mainz]

Requesting r=/sr= ...

Comment 35

[Christopher Blizzard (:blizzard)]

Comment on attachment 87429 [details] [diff] [review]
Patch for 2002-06-07-08-trunk

sr=blizzard

Comment 36

[Roland Mainz]

Attachment: Patch for both GTK+ gfx and Xlib gfx

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... ;-(

Comment 37

[Roland Mainz]

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) ...

Comment 38

[tor]

Comment on attachment 87432 [details] [diff] [review]
Patch for both GTK+ gfx and Xlib gfx

r=tor

Comment 39

[Roland Mainz]

Fix checked in into "trunk"
(http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1023923040&maxdate=1023923460&who=jkeiser%25netscape.com)
...

Comment 40

[Roland Mainz]

Taking bug myself...

----

Requesting a= for 1.0.1-branch...

Comment 41

[Sven Esbjerg]

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!

Comment 42

[Ed Grochowski]

This sounds like a duplicate of bug 120238

Comment 43

[Ben Guthrie]

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" <[e-mail]>
Date: Thu, 13 Jun 2002 06:39:35 +0100 (BST)
CC: "BugTraq Mailing List" <[e-mail]>, "Linux Kernel Mailing
List" <[e-mail]>
From: "Alan Cox" <[e-mail]> 

> 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

Comment 44

[R.K.Aa.]

*** Bug 151616 has been marked as a duplicate of this bug. ***

Comment 45

[Daniel S Kurushin]

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.

Comment 46

[Diego Biurrun]

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...

Comment 47

[Diego Biurrun]

*** Bug 120238 has been marked as a duplicate of this bug. ***

Comment 48

[Mark Hammond [:markh] [:mhammond]]

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.

Comment 49

[Andrew Schultz]

tested a trunk build and it doesn't crash xfs.  isn't this FIXED (on trunk)?

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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"

Comment 51

[Christopher Blizzard (:blizzard)]

Checked into the 1.0 branch.

Comment 52

[Diego Biurrun]

The URL seems to have changed, changing to the URL of the dupe.

Comment 53

[Yuying Long]

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.

Comment 54

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 115788 has been marked as a duplicate of this bug. ***