Closed Bug 303901 Opened 19 years ago Closed 17 years ago

crash [@ _moz_cairo_surface_set_user_data] on this malformed .html page


(Core :: Graphics, defect, P1)






(Reporter: tommy, Assigned: MatsPalmgren_bugz)



(Keywords: crash, testcase, Whiteboard: [sg:nse null-deref])

Crash Data


(5 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

When accessing a malformed .html page, Deer Park 2 will segfault.  I have
attached the malformed .html file for your review.  This only seems to affect
the Linux version of Deer Park 2.


Tom Ferris
Key fingerprint = 0DFA 6275 BA05 0380 DD91 34AD C909 A338 D1AF 5D78

Reproducible: Always

Steps to Reproduce:
1.  Browse to the malformed .html via a webserver.

Actual Results:  
Deer Park 2 will segfault.

Expected Results:  
Should properly parse the .html page.
Attached file deerpark-death.html
Place this on a webserver in order to re-produce the issue.
Attachment #191973 - Attachment description: PoC → deerpark-death.html
No crash on Mac (Aug 7 trunk), loading the attachment through Bugzilla.
Keywords: crash
Summary: Deer Park 2 Malformed .html Denial Of Service → Deer Park Alpha 2 crashes on this malformed .html page
Blocks: Zalewski
(In reply to comment #2)
> No crash on Mac (Aug 7 trunk), loading the attachment through Bugzilla.

Any updates on this???
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050817

I see bug 305029 but I don't get a crash.

I'll try to find someone who can test on Linux.
I have tried to reproduce this bug in both Deer Park alpha 2 (Mozilla/5.0 (X11;
U; Linux i686; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+) and the latest
Firefox nightly (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1)
Gecko/20050817 Firefox/1.6a1), and I am unable to reproduce it in either build.
 I'm running Fedora Core 4 in case it matters.
Tom, since we can't reproduce the crash, can you attach a stack trace or give a
Talkback ID?
Whiteboard: [sg:needinfo] WFM, hoping for stack trace
No crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050817 Firefox/1.0+
I cannot reproduce this with a current trunk opt Seamonkey Linux build, a
Seamonkey opt Linux nightly from 2005-07-12, a current trunk debug Firefox Lonux
build, or a current trunk opt Firefox Linux nightly... 
No crash or valgrind warnings on a Linux build of Aviary 1.0.1 branch (plus
patch for bug 307259).
Er, sorry, that was a trunk build.
WFM Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060111 Firefox/1.6a1.

Tom, please reopen if you can still reproduce this bug in a current version (e.g. Firefox 1.5, a 1.5.0.x nightly, or a trunk nightly), and include a stack trace or Talkback ID or reduced testcase if you can.
Closed: 19 years ago
Resolution: --- → WORKSFORME
i will look into it today.
I just verified that the bugs still works on the current 1.5 (build 2005111116) on linux only.  This does not affect OS X, or win32.  Please see the link below for the simplified testcase:


-- Tom
Resolution: WORKSFORME → ---
Version: unspecified → 1.5 Branch
Depends on: 323380
Depends on: 305029
Depends on: 323381
mrbkap tried to reproduce this but wasn't able to.  I filed bugs on some of the assertions and warnings he hit, and made them block this bug.  He also hit an assertion in nsRenderingContextGTK::CreateDrawingSurface, but I can't reproduce that on Mac for obvious reasons, so I didn't file a bug on that.

Tom, can you provide a stack trace or Talkback ID for the crash you're hitting?  That might contain enough information for us to fix the bug even though we can't reproduce it.
Keywords: testcase
To be clear, the gtk assertion I saw was only when I made the iframe's width extremely large (probably too large to contain in a PRUint32), not on the actual testcase.

I was wondering if perhaps Tom was finding an out-of-memory edgecase in his crashes.
This testcase reminds me strongly of bug 303433, for what it's worth...
I just sent the crash report via talkback.  The talkback ID is:


I hope this helps.  ;) 
Jay, is there a reason that the talkback from comment 17 has no stack?

In any case, the relevant thing from that report is:

  Trigger Reason: SIGFPE: Floating Point Exception: (signal 8)

So it's not a segmentation violation, for what it's worth.
bz: Talkback on Linux can be flaky sometimes, and as you said, the trigger reason is not a typical crash, so it is possible that Talkback doesn't know how to capture the stack for this particular crash.  If anyone else is able to reproduce this again, please post your Talkback incident id so we can see if this is a common problem with Floating Point Exceptions.
Tom, assuming you still see this and Talkback still doesn't give you a useful stack, I suggest trying to reproducing it in gdb with a debug build of Firefox.  I bet that would give you a useful stack, at least.  You could also try running a build with symbols in Valgrind, but that's a bit more painful.
Tom, are you still seeing this problem in any current builds?
- crash confirmed

Build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/2007052204 Minefield/3.0a5pre on Fedora FC 6

while executing the testcase from comment #1 minefield trunk crash with segfaul  firefox 
/opt/firefox/ line 131:  2940 Segmentation fault      "$prog" ${1+"$@"}

talkback is not comming up on this crash. 

Ever confirmed: true
Whiteboard: [sg:needinfo] WFM, hoping for stack trace → WFM, hoping for stack trace
Not that it appears to help much, but ssidler got TB32405754W with a trunk build.
I just got TB32406162G with symbols.
Whiteboard: WFM, hoping for stack trace
Version: 1.5.0.x Branch → Trunk
Both Tomcat and ss crash on trunk, neither on's possible we're
seeing a different problem altogether. This bug was originally written about
what became the 1.8 branch.

Boris's comment 18 from 2006 is a different kind of crash than comment 22 or
comment 23
The new crash is in Cairo, over to Vlad for further triage. Is this one an exploitable crash?
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
Summary: Deer Park Alpha 2 crashes on this malformed .html page → crash [@ _moz_cairo_surface_set_user_data] on this malformed .html page
Assignee: nobody → vladimir
Flags: blocking1.9?
I think that the branch and trunk crashes are very different.  The trunk crash is fallout from bug 371135; a null surface is making its way to the spot indicated in talkback, and it's causing a crash when dereferenced.
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9alpha6
Attached file Testcase #2
Attached file stack
Attached patch Patch rev. 1Splinter Review
I haven't compiled the the BeOS part, but I thought I'd include
it anyway since it's trivial.
Assignee: vladimir → mats.palmgren
Attachment #269911 - Flags: superreview?(vladimir)
Attachment #269911 - Flags: review?(vladimir)
(In reply to comment #26)
> The new crash is in Cairo, over to Vlad for further triage. Is this one an
> exploitable crash?

I don't think so, all the fixed spots (on trunk) would be null-ptr accesses.
The testcases does not crash my 1.8, 1.8.0 branch debug builds (tried both
punting remaining a6 bugs to b1, all of these shipped in a5, so we're at least no worse off by doing so.
Target Milestone: mozilla1.9alpha6 → mozilla1.9beta1
Comment on attachment 269911 [details] [diff] [review]
Patch rev. 1

Looks fine, just a few comments... r+ with these changes made.

>@@ -1738,34 +1745,38 @@ nsWindow::OnExposeEvent(GtkWidget *aWidg
>     // operations below if that happened - it will lead to XError and exit().
>     if (NS_LIKELY(!mIsDestroyed)) {
>         if (status != nsEventStatus_eIgnore) {
>             if (translucent) {
>                 nsRefPtr<gfxPattern> pattern = ctx->PopGroup();
>                 ctx->SetOperator(gfxContext::OPERATOR_SOURCE);
>                 ctx->SetPattern(pattern);
>                 ctx->Paint();
>                 nsRefPtr<gfxImageSurface> img =
>                     new gfxImageSurface(gfxIntSize(boundsRect.width, boundsRect.height),
>                                         gfxImageSurface::ImageFormatA8);
>-                img->SetDeviceOffset(gfxPoint(-boundsRect.x, -boundsRect.y));
>+                if (img) {
>+                    img->SetDeviceOffset(gfxPoint(-boundsRect.x, -boundsRect.y));

Need to check if (img && !img->CairoStatus()) { ... }

>-                nsRefPtr<gfxContext> imgCtx = new gfxContext(img);
>-                imgCtx->SetPattern(pattern);
>-                imgCtx->SetOperator(gfxContext::OPERATOR_SOURCE);
>-                imgCtx->Paint();
>-                UpdateTranslucentWindowAlphaInternal(nsRect(boundsRect.x, boundsRect.y,
>-                                                            boundsRect.width, boundsRect.height),
>-                                                     img->Data(), img->Stride());

>@@ -5820,25 +5831,32 @@ nsWindow::GetThebesSurface()
>     mThebesSurface = nsnull;
>     if (!mThebesSurface) {
>         GdkDrawable* d = GDK_DRAWABLE(mDrawingarea->inner_window);
>         gint width, height;
>         gdk_drawable_get_size(d, &width, &height);
>         if (!gfxPlatform::UseGlitz()) {
>             mThebesSurface = new gfxXlibSurface
>                 (GDK_WINDOW_XDISPLAY(d),
>                  GDK_WINDOW_XWINDOW(d),
>                  GDK_VISUAL_XVISUAL(gdk_drawable_get_visual(d)),
>                  gfxIntSize(width, height));
>-            gfxPlatformGtk::GetPlatform()->SetSurfaceGdkWindow(mThebesSurface, GDK_WINDOW(d));
>+            if (mThebesSurface) {
>+                if (mThebesSurface->CairoStatus() == CAIRO_STATUS_SUCCESS) {
>+                    gfxPlatformGtk::GetPlatform()->SetSurfaceGdkWindow(mThebesSurface, GDK_WINDOW(d));
>+                }
>+                else {
>+                    mThebesSurface = nsnull;   
>+                }
>+            }

Would rather see this written as 
  if (mThebesSurface && !mThebesSurface->CairoStatus()) {
    ... SetSurfaceGdkWindow
  } else {
    mThebesSurface = nsnull;

(Don't want to expose CAIRO_* constants; I just don't have a better solution yet)
Attachment #269911 - Flags: superreview?(vladimir)
Attachment #269911 - Flags: superreview+
Attachment #269911 - Flags: review?(vladimir)
Attachment #269911 - Flags: review+
Fixed the nits above as suggested and checked in:
mozilla/widget/src/gtk2/nsWindow.cpp 	1.222 	mozilla/widget/src/xpwidgets/nsBaseWidget.cpp 	1.159 	mozilla/widget/src/beos/nsWindow.cpp 	1.137 

This is for the later Cairo crash which this bug mutated into.

The branch crash that was originally reported is WFM as far as I can tell,
I tested Linux and MacOSX branch builds.
(It appears that one was Linux-only, comment 4 and comment 7)

Closed: 19 years ago17 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Flags: wanted1.8.1.x-
Flags: wanted1.8.0.x-
Whiteboard: [sg:nse null-deref]
Group: security
verified using verified fixed using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050804 Minefield/3.0pre and the testcase - no crash on testcase

--> Verified fixed

crash test landed
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ _moz_cairo_surface_set_user_data]
You need to log in before you can comment on or make changes to this bug.