[pango?] hidden text and browser crash when loading page with 0 byte and justified paragraph

RESOLVED DUPLICATE of bug 366902

Status

()

Core
Layout
--
critical
RESOLVED DUPLICATE of bug 366902
12 years ago
9 years ago

People

(Reporter: Patrick Mairif, Assigned: Behdad Esfahbod)

Tracking

({crash})

1.8 Branch
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060606 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060606 Firefox/1.5.0.4

When loading a prepared UTF-8 encoded xhtml file the text between a null byte and the next html tag is hidden. When loading that file from disk or loading that file from a webserver with content type text/html, the browser hangs or crashes. When loading it with xml content type, the first '<' of the next tag disappears and the xml file gets corrupted, but the browser does not crash.

Reproducible: Always

Steps to Reproduce:
1. load the file
2. see what happens


Actual Results:  
hidden text, browser hangs or crashes

Expected Results:  
visible text, no crash

system default encoding is UTF-8
(Reporter)

Comment 1

12 years ago
Created attachment 230868 [details]
file that causes the crash

Warning! Save your data before opening that file in your browser!
(Reporter)

Comment 2

12 years ago
Created attachment 230869 [details]
second example

Warning! Save your data before opening that file in your browser!
Component: General → HTML: Parser
Product: Firefox → Core
Version: unspecified → 1.8 Branch
Assignee: nobody → mrbkap
QA Contact: general → parser
Do you crash on these testcases (loaded from the bug)? I don't using a ff2 debug build. Is my build fixed, or did the problem get stripped on upload?
Attachment #230868 - Attachment mime type: text/html → text/xml
Attachment #230868 - Attachment mime type: text/xml → text/html
I don't crash using a release 1.5.0.4 either
I don't crash using the first testcase with Linux Firefox 1.5.0.4 after saving to disk, on a system where the system encoding is UTF-8.
(Reporter)

Comment 6

12 years ago
Yes, my browser crashes when loading the attached testcases. It's reproducable on two different systems, both are gentoo systems with firefox 1.5.0.4.
Mozilla 1.7.13 on one of the systems does NOT reproduce the bug.

Comment 7

12 years ago
With the Firefox 1.5.0.5 latest debug build here on Solaris(I made it myself), the two testcases don't crash.
(Reporter)

Comment 8

12 years ago
Additional info: I get the following notice on the console, when firefox hangs:
(Gecko:19305): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()
(Reporter)

Comment 9

12 years ago
Ok, it's not a gentoo thing. Report from a debian system:

Firefox crashes (freeze):
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060406
Firefox/1.5.0.4 (Debian-1.5.dfsg+1.5.0.4-1)

Epiphany does not crash, but refuses to show or save the html source:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060608
(Debian-1.8.0.4-1) Epiphany/2.14
All those are pango-enabled releases and you got a pango warning -- a clue?. The official Mozilla Firefox binaries do not use pango, could you download and test a release from http://releases.mozilla.org/pub/mozilla.org/firefox and see if the problem goes away?

If you still see the bug then we need to keep looking at what other differences might cause you to see this problem when we don't.

If the bug goes away with official releases it's almost certainly related to pango. Might be in our use of pango, or in pango itself.
Assignee: mrbkap → nobody
Component: HTML: Parser → Layout
Keywords: crash
QA Contact: parser → layout
Summary: hidden text and browser crash when loading page with 0 byte and justified paragraph → [pango?] hidden text and browser crash when loading page with 0 byte and justified paragraph
Whiteboard: [sg:investigate]
We also have to determine if this is an unexploitable crash so we can open up the bug (and thus get more folks looking at it) or if it needs to remain security-sensitive.
(Assignee)

Comment 12

12 years ago
I've got to look into it.  Pango historically didn't allow embedded NUL.  It will treat it as a premature end of string even if a length parameter is passed on.  I'm going to fix that properly.

Next is the fact that gfx/src/gtk/nsFontMetricsPango converts from UTF-16 to UTF-8 and calls strlen on the restult, assuming no embedded NUL.

To fix it properly, Pango should be fixed to allow embedded NUL.  That's not really too far.  And nsFontMetricsPango should not make any such assumptions either.  In the mean time, we can fix it in nsFontMetricsPango by replacing NUL bytes with a 0xff byte.  You'll get the Pango warning, but it will work otherwise.

I can cook a patch if this looks good.
(Assignee)

Comment 13

12 years ago
Ok, trying to fix this led to an almost rewrite of the nsFontMetricsPango code.  I wanted to clean it up for so long.  Finally did.  The final patch is attached to bug 357733.  That one includes Pango printing bits too.  For this bug, just picking the gfx/src/gtk changes is enough.
I'll take comment 12 and 13 as confirmation. Marking dependent on bug 357733 and removing security flag because the crash is not in Firefox.
Assignee: nobody → mozilla
Group: security
Status: UNCONFIRMED → NEW
Depends on: 357733
Ever confirmed: true
Whiteboard: [sg:investigate]

Comment 15

9 years ago
Created attachment 412448 [details]
first testcase, with &#0; instead of null byte that gets turned into U+FFFD

Comment 16

9 years ago
None of these testcases crashes my Firefox trunk debug build on Ubuntu 9.10.

I think mozilla.com builds use Pango, so I'm not sure what comment 14 was about.

Updated

9 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 366902
You need to log in before you can comment on or make changes to this bug.