crash [@ _moz_cairo_surface_set_user_data] on this malformed .html page

VERIFIED FIXED in mozilla1.9alpha8

Status

()

Core
Graphics
P1
critical
VERIFIED FIXED
13 years ago
7 years ago

People

(Reporter: Tom Ferris, Assigned: mats)

Tracking

({crash, testcase})

Trunk
mozilla1.9alpha8
x86
Linux
crash, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
wanted1.8.1.x -
wanted1.8.0.x -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(5 attachments)

(Reporter)

Description

13 years ago
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.

Thanks,

-- 
Tom Ferris
Researcher
www.security-protocols.com
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.
(Reporter)

Comment 1

13 years ago
Created attachment 191973 [details]
deerpark-death.html

Place this on a webserver in order to re-produce the issue.
(Reporter)

Updated

13 years ago
Attachment #191973 - Attachment description: PoC → deerpark-death.html

Comment 2

12 years ago
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

Updated

12 years ago
Blocks: 264944
(Reporter)

Comment 3

12 years ago
(In reply to comment #2)
> No crash on Mac (Aug 7 trunk), loading the attachment through Bugzilla.

Any updates on this???

Comment 4

12 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050817
Firefox/1.0+

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.

Comment 6

12 years ago
Tom, since we can't reproduce the crash, can you attach a stack trace or give a
Talkback ID?

Updated

12 years ago
Whiteboard: [sg:needinfo] WFM, hoping for stack trace

Comment 7

12 years ago
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.

Comment 11

12 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 12

12 years ago
i will look into it today.
(Reporter)

Comment 13

12 years ago
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:

http://www.security-protocols.com/moz/ff-linux-dos.html

Thanks,

-- Tom
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Version: unspecified → 1.5 Branch

Updated

12 years ago
Depends on: 323380

Updated

12 years ago
Depends on: 305029

Updated

12 years ago
Depends on: 323381

Comment 14

12 years ago
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.

Updated

12 years ago
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...
(Reporter)

Comment 17

12 years ago
I just sent the crash report via talkback.  The talkback ID is:

TB14027492Z

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.

Comment 19

12 years ago
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.

Comment 20

12 years ago
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/run-mozilla.sh: line 131:  2940 Segmentation fault      "$prog" ${1+"$@"}

talkback is not comming up on this crash. 

Status: UNCONFIRMED → NEW
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 2.0.0.4--it'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
Priority: -- → P1
(Assignee)

Comment 28

11 years ago
Created attachment 269908 [details]
Testcase #2
(Assignee)

Comment 29

11 years ago
Created attachment 269909 [details]
stack
(Assignee)

Comment 30

11 years ago
Created attachment 269911 [details] [diff] [review]
Patch rev. 1

I haven't compiled the the BeOS part, but I thought I'd include
it anyway since it's trivial.
Assignee: vladimir → mats.palmgren
Status: NEW → ASSIGNED
Attachment #269911 - Flags: superreview?(vladimir)
Attachment #269911 - Flags: review?(vladimir)
(Assignee)

Comment 31

11 years ago
Created attachment 269912 [details] [diff] [review]
Patch rev. 1 (diff -w)
(Assignee)

Comment 32

11 years ago
(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
gtk1/2).

Updated

11 years ago
Duplicate of this bug: 386116
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+
(Assignee)

Comment 36

11 years ago
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)

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago11 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

Status: RESOLVED → VERIFIED

Comment 38

9 years ago
crash test landed
http://hg.mozilla.org/mozilla-central/rev/18ef88791678
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.