Mozilla Firefox 29.0 crash (pointing to Null ) with window.open and very large sizes (PushClipsToDT signature)

RESOLVED WORKSFORME

Status

()

defect
--
critical
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: mr.k4rizma, Unassigned)

Tracking

(Depends on 2 bugs, 4 keywords)

29 Branch
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Just open the following poc 

</pre>
<a href="javascript:fload()"
onclick="window.open('about:blank','1','toolbar=yes,location=yes,directories=yes,status=yes,menubar=yes,scrollbars=yes,resizable=yes,width=9999999999,height=9999999999');"
>Start</a>
<br>



Mozilla firefox crash 
Rapport 
Details 

AdapterDeviceID: 0x0000
AdapterVendorID: 0x0000
Add-ons: %7B9c51bd27-6ed8-4000-a2bf-36cb95c0c947%7D:11.0.1,YoutubeDownloader%40PeterOlayev.com:2.3.0,mozilla_cc%40internetdownloadmanager.com:7.3.72,%7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D:29.0.1
AvailablePageFile: 1214533632
AvailablePhysicalMemory: 15548416
AvailableVirtualMemory: 1893470208
BIOS_Manufacturer: Award Software International, Inc.
BlockedDllList: 
BreakpadReserveAddress: 55508992
BreakpadReserveSize: 37748736
BuildID: 20140506152807
CrashTime: 1400184213
EMCheckCompatibility: true
FramePoisonBase: 00000000f0de0000
FramePoisonSize: 65536
InstallTime: 1399992625
Notes: AdapterVendorID: 0x0000, AdapterDeviceID: 0x0000, AdapterSubsysID: 00000000, AdapterDriverVersion: 
D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- 
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: release
SecondsSinceLastCrash: 852
StartupTime: 1400184183
SystemMemoryUsePercentage: 98
Theme: classic/1.0
Throttleable: 1
TotalVirtualMemory: 2147352576
Vendor: Mozilla
Version: 29.0.1
Winsock_LSP: MSAFD Tcpip [TCP/IP] : 2 : 1 : ᆊ粑 
 MSAFD Tcpip [UDP/IP] : 2 : 2 : ᆊ粑 
 MSAFD Tcpip [RAW/IP] : 2 : 3 : ᆊ粑 
 RSVP UDP Service Provider : 6 : 2 : ᆊ粑 
 RSVP TCP Service Provider : 6 : 1 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{BD4BD2F6-A883-4476-AAA4-13D88F2CEA1B}] SEQPACKET 0 : 2 : 5 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{BD4BD2F6-A883-4476-AAA4-13D88F2CEA1B}] DATAGRAM 0 : 2 : 2 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{8D4F5C1C-DCE7-4880-85C0-C0D3565F531B}] SEQPACKET 1 : 2 : 5 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{8D4F5C1C-DCE7-4880-85C0-C0D3565F531B}] DATAGRAM 1 : 2 : 2 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{479EEFC9-7941-4BAF-9DBB-73DFBDFE05F5}] SEQPACKET 2 : 2 : 5 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{479EEFC9-7941-4BAF-9DBB-73DFBDFE05F5}] DATAGRAM 2 : 2 : 2 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{FD196690-E16A-4B46-83D4-A7329A14BDAA}] SEQPACKET 3 : 2 : 5 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{FD196690-E16A-4B46-83D4-A7329A14BDAA}] DATAGRAM 3 : 2 : 2 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{47E6F84F-F0B7-4EEE-B701-FE3C94C9FADE}] SEQPACKET 4 : 2 : 5 : ᆊ粑 
 MSAFD NetBIOS [\Device\NetBT_Tcpip_{47E6F84F-F0B7-4EEE-B701-FE3C94C9FADE}] DATAGRAM 4 : 2 : 2 : ᆊ粑
useragent_locale: fr

Comment 1

5 years ago
Please link to your crash report ID; I don't think this bug needs to remain private but I'd like to check the stack to be certain before opening it up.

https://developer.mozilla.org/en-US/docs/How_to_get_a_stacktrace_for_a_bug_report#How_to_get_a_crash_ID_with_the_Mozilla_Crash_Reporter
Flags: needinfo?(mr.k4rizma)

Comment 3

5 years ago
Excellent, thank you. This is a known OOM crash signature which is not exploitable. It's exciting to me that you have clear steps to reproduce! Bas, look!
Group: core-security
Status: UNCONFIRMED → NEW
Component: Security → Graphics: Layers
Ever confirmed: true
Flags: needinfo?(bas)
Product: Firefox → Core
For what its worth I cannot reproduce the OOM crash with the attachment.  Tried with nightly and FF29 on my win8.1 64-bit machine.

Comment 5

5 years ago
Crashes for me on nightly.

Updated

5 years ago
Blocks: 805406
Crash Signature: [@ gfxContext::PushClipsToDT(mozilla::gfx::DrawTarget*) ]
Summary: Mozilla Firefox 29.0 crash (pointing to Null ) → Mozilla Firefox 29.0 crash (pointing to Null ) with window.open and very large sizes (PushClipsToDT signature)

Comment 6

5 years ago
Went through in a debugger:

hit
NS_ERROR("Failed to create mask!")
>	xul.dll!gfxAlphaBoxBlur::Paint(aDestinationCtx=0x0e6d9d58)  Line 112	C++
 	xul.dll!gfxAlphaBoxBlur::BlurRectangle(aDestinationCtx=0x0e6d9d58, aRect={...}, aCornerRadii=0x00000000, aBlurStdDev={...}, aShadowColor={...}, aDirtyRect={...}, aSkipRect={...})  Line 177	C++
 	xul.dll!nsContextBoxBlur::BlurRectangle(aDestinationCtx=0x0e6d9d58, aRect={...}, aAppUnitsPerDevPixel=0x0000003c, aCornerRadii=0x00000000, aBlurRadius=0x00000708, aShadowColor={...}, aDirtyRect={...}, aSkipRect={...})  Line 5211	C++
 	xul.dll!nsCSSRendering::PaintBoxShadowOuter(aPresContext=0x05acfc50, aRenderingContext={...}, aForFrame=0x0e87e240, aFrameArea={...}, aDirtyRect={...}, aOpacity=1.0000000)  Line 1370	C++
 	xul.dll!nsDisplayBoxShadowOuter::Paint(aBuilder=0x003ba7d8, aCtx=0x0e4988d0)  Line 2856	C++
 	xul.dll!mozilla::FrameLayerBuilder::PaintItems(aItems={...}, aRect={...}, aContext=0x0e6d9d58, aRC=0x0e4988d0, aBuilder=0x003ba7d8, aPresContext=0x05acfc50, aOffset={...}, aXScale=1.0000000, aYScale=1.0000000, aCommonClipCount=0x00000000)  Line 3699	C++
 	xul.dll!mozilla::FrameLayerBuilder::DrawThebesLayer(aLayer=0x05ab6048, aContext=0x0e6d9d58, aRegionToDraw={...}, aClip={...}, aRegionToInvalidate={...}, aCallbackData=0x003ba7d8)  Line 3856	C++
 	xul.dll!mozilla::layers::ClientThebesLayer::PaintThebes()  Line 79	C++
 	xul.dll!mozilla::layers::ClientThebesLayer::RenderLayer()  Line 123	C++
 	xul.dll!mozilla::layers::ClientContainerLayer::RenderLayer()  Line 64	C++
 	xul.dll!mozilla::layers::ClientLayerManager::EndTransactionInternal(aCallback=0x0f2f86b3, aCallbackData=0x003ba7d8, __formal=END_DEFAULT)  Line 207	C++
 	xul.dll!mozilla::layers::ClientLayerManager::EndTransaction(aCallback=0x0f2f86b3, aCallbackData=0x003ba7d8, aFlags=END_DEFAULT)  Line 233	C++
 	xul.dll!nsDisplayList::PaintForFrame(aBuilder=0x003ba7d8, aCtx=0x00000000, aForFrame=0x0d1a62b8, aFlags=0x0000000d)  Line 1370	C++
 	xul.dll!nsDisplayList::PaintRoot(aBuilder=0x003ba7d8, aCtx=0x00000000, aFlags=0x0000000d)  Line 1211	C++
 	xul.dll!nsLayoutUtils::PaintFrame(aRenderingContext=0x00000000, aFrame=0x0d1a62b8, aDirtyRegion={...}, aBackstop=0x00000000, aFlags=0x00000304)  Line 2825	C++
 	xul.dll!PresShell::Paint(aViewToPaint=0x0d603620, aDirtyRegion={...}, aFlags=0x00000001)  Line 5917	C++
 	xul.dll!nsViewManager::ProcessPendingUpdatesPaint(aWidget=0x05ef8b68)  Line 443	C++
 	xul.dll!nsViewManager::ProcessPendingUpdatesForView(aView=0x0d603620, aFlushDirtyRegion=true)  Line 386	C++
 	xul.dll!nsViewManager::ProcessPendingUpdates()  Line 1075	C++
 	xul.dll!nsViewManager::WillPaintWindow(aWidget=0x05ef8b68)  Line 681	C++
 	xul.dll!nsView::WillPaintWindow(aWidget=0x05ef8b68)  Line 1041	C++
 	xul.dll!nsWindow::OnPaint(aDC=0x00000000, aNestingLevel=0x00000000)  Line 289	C++

In a normal debug build, Firefox then exits without any further spew, and without an exception in the debugger.

If I enable the crash reporter, it is triggered.

Comment 7

5 years ago
By breaking in the exception handler, I get this stack:

 	xul.dll!nsXULAppInfo::WriteMinidumpForException(aExceptionInfo=0x002a9590)  Line 1098	C++
 	xul.dll!mozilla::ReportException(aExceptionInfo=0x002a9590)  Line 27	C++
 	xul.dll!CallWindowProcCrashProtected(aWndProc=0x0f76044b, aHWnd=0x00330946, aMsg=0x0000000f, aWParam=0x00000000, aLParam=0x00000000)  Line 37	C++
 	msvcr100d.dll!@_EH4_CallFilterFunc@8() 	
 	xul.dll!_except_handler4(ExceptionRecord=0x002a96a4, EstablisherFrame=0x002ab708, ContextRecord=0x002a96f4, DispatcherContext=0x002a9678) 	C
 	ntdll.dll!ExecuteHandler2@20() 	
 	ntdll.dll!ExecuteHandler@20() 	
 	ntdll.dll!_RtlDispatchException@8() 	
 	ntdll.dll!_KiUserExceptionDispatcher@8() 	
 	xul.dll!gfxContext::PushClipsToDT(aDT=0x00000000)  Line 2122	C++
 	xul.dll!gfxContext::PushGroup(content={...})  Line 1592	C++
 	xul.dll!AutoCairoPixmanBugWorkaround::AutoCairoPixmanBugWorkaround(aContext=0x083469d8, aDeviceSpaceToImageSpace={...}, aFill={...}, aSurface=0x082fb478)  Line 336	C++
 	xul.dll!gfxUtils::DrawPixelSnapped(aContext=0x083469d8, aDrawable=0x17f73a18, aUserSpaceToImageSpace={...}, aSubimage={...}, aSourceRect={...}, aImageRect={...}, aFill={...}, aFormat={...}, aFilter={...}, aImageFlags=0x00000018)  Line 461	C++
 	xul.dll!imgFrame::Draw(aContext=0x083469d8, aFilter={...}, aUserSpaceToImageSpace={...}, aFill={...}, aPadding={...}, aSubimage={...}, aImageFlags=0x00000018)  Line 544	C++
 	xul.dll!mozilla::image::RasterImage::DrawWithPreDownscaleIfNeeded(aFrame=0x06eeb138, aContext=0x083469d8, aFilter={...}, aUserSpaceToImageSpace={...}, aFill={...}, aSubimage={...}, aFlags=0x00000018)  Line 2672	C++
 	xul.dll!mozilla::image::RasterImage::Draw(aContext=0x083469d8, aFilter={...}, aUserSpaceToImageSpace={...}, aFill={...}, aSubimage={...}, __formal={...}, __formal={...}, aWhichFrame=0x00000001, aFlags=0x00000018)  Line 2766	C++
 	xul.dll!DrawImageInternal(aRenderingContext=0x17ff9240, aImage=0x0866d8c8, aGraphicsFilter={...}, aDest={...}, aFill={...}, aAnchor={...}, aDirty={...}, aImageSize={...}, aSVGContext=0x00000000, aImageFlags=0x00000018)  Line 4855	C++
 	xul.dll!nsLayoutUtils::DrawSingleImage(aRenderingContext=0x17ff9240, aImage=0x0866d8c8, aGraphicsFilter={...}, aDest={...}, aDirty={...}, aSVGContext=0x00000000, aImageFlags=0x00000010, aSourceArea=0x00000000)  Line 4977	C++
 	xul.dll!nsImageBoxFrame::PaintImage(aRenderingContext={...}, aDirtyRect={...}, aPt={...}, aFlags=0x00000010)  Line 341	C++
 	xul.dll!nsDisplayXULImage::Paint(aBuilder=0x002aa798, aCtx=0x17ff9240)  Line 356	C++
 	xul.dll!mozilla::FrameLayerBuilder::PaintItems(aItems={...}, aRect={...}, aContext=0x083469d8, aRC=0x17ff9240, aBuilder=0x002aa798, aPresContext=0x0abdb758, aOffset={...}, aXScale=1.0000000, aYScale=1.0000000, aCommonClipCount=0x00000000)  Line 3699	C++
 	xul.dll!mozilla::FrameLayerBuilder::DrawThebesLayer(aLayer=0x0adfc0a8, aContext=0x083469d8, aRegionToDraw={...}, aClip={...}, aRegionToInvalidate={...}, aCallbackData=0x002aa798)  Line 3856	C++
 	xul.dll!mozilla::layers::ClientThebesLayer::PaintThebes()  Line 79	C++
 	xul.dll!mozilla::layers::ClientThebesLayer::RenderLayer()  Line 123	C++
 	xul.dll!mozilla::layers::ClientContainerLayer::RenderLayer()  Line 64	C++
 	xul.dll!mozilla::layers::ClientLayerManager::EndTransactionInternal(aCallback=0x0f6386b3, aCallbackData=0x002aa798, __formal=END_DEFAULT)  Line 207	C++
 	xul.dll!mozilla::layers::ClientLayerManager::EndTransaction(aCallback=0x0f6386b3, aCallbackData=0x002aa798, aFlags=END_DEFAULT)  Line 233	C++
 	xul.dll!nsDisplayList::PaintForFrame(aBuilder=0x002aa798, aCtx=0x00000000, aForFrame=0x06f1be88, aFlags=0x0000000d)  Line 1370	C++
 	xul.dll!nsDisplayList::PaintRoot(aBuilder=0x002aa798, aCtx=0x00000000, aFlags=0x0000000d)  Line 1211	C++
 	xul.dll!nsLayoutUtils::PaintFrame(aRenderingContext=0x00000000, aFrame=0x06f1be88, aDirtyRegion={...}, aBackstop=0x00000000, aFlags=0x00000304)  Line 2825	C++
 	xul.dll!PresShell::Paint(aViewToPaint=0x0adc0df0, aDirtyRegion={...}, aFlags=0x00000001)  Line 5917	C++
 	xul.dll!nsViewManager::ProcessPendingUpdatesPaint(aWidget=0x083d0e88)  Line 443	C++
 	xul.dll!nsViewManager::ProcessPendingUpdatesForView(aView=0x0adc0df0, aFlushDirtyRegion=true)  Line 386	C++
 	xul.dll!nsViewManager::ProcessPendingUpdates()  Line 1075	C++
 	xul.dll!nsViewManager::WillPaintWindow(aWidget=0x083d0e88)  Line 681	C++
 	xul.dll!nsView::WillPaintWindow(aWidget=0x083d0e88)  Line 1041	C++
 	xul.dll!nsWindow::OnPaint(aDC=0x00000000, aNestingLevel=0x00000000)  Line 289	C++
 	xul.dll!nsWindow::ProcessMessage(msg=0x0000000f, wParam=0x00000000, lParam=0x00000000, aRetValue=0x002ab6bc)  Line 4825	C++
 	xul.dll!nsWindow::WindowProcInternal(hWnd=0x00330946, msg=0x0000000f, wParam=0x00000000, lParam=0x00000000)  Line 4402	C++
 	xul.dll!CallWindowProcCrashProtected(aWndProc=0x0f76044b, aHWnd=0x00330946, aMsg=0x0000000f, aWParam=0x00000000, aLParam=0x00000000)  Line 35	C++
 	xul.dll!nsWindow::WindowProc(hWnd=0x00330946, msg=0x0000000f, wParam=0x00000000, lParam=0x00000000)  Line 4354	C++

Comment 8

5 years ago
The core problem seems to be that gfxContext::PushNewDT is fallible but doesn't return error codes and isn't error-checked. Bas how tangled would it be to make that a fallible method?

Comment 9

5 years ago
Range for the first crashing build (lots of xul.dll in the signature):
https://crash-stats.mozilla.com/report/index/cec47de8-5a40-4943-82bc-1fc552140521

m-c:
Last good revision: 5811efc11011 (2014-04-09)
First bad revision: 690c810c8e3e (2014-04-10)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5811efc11011&tochange=690c810c8e3e

m-i:
Last good revision: bf165cddae07
First bad revision: d17583440ac0
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bf165cddae07&tochange=d17583440ac0



Range for the first crashing build with PushClipsToDT-signature:
https://crash-stats.mozilla.com/report/index/f82d441d-b151-4089-88be-010f92140521

m-c:
Last good revision: 53a6c96cea62 (2014-04-20)
First bad revision: 5010b38abf18 (2014-04-21)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=53a6c96cea62&tochange=5010b38abf18

m-i:
inbound-builds are crashing with xul.dll-signatures, even in the latest builds as of today.
xul.dll signatures for older nightlies and for inbound are because we only keep crash-stats symbols for 30 days of nightly builds, and not at all for inbound builds.

Updated

5 years ago
Keywords: crash

Updated

5 years ago
Duplicate of this bug: 1015111

Updated

5 years ago
Severity: normal → critical
Keywords: regression, testcase
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #8)
> The core problem seems to be that gfxContext::PushNewDT is fallible but
> doesn't return error codes and isn't error-checked. Bas how tangled would it
> be to make that a fallible method?

We could make it fallible. It would be a little bit of work to make other code deal with this though (the next popgroup would probably need to take it into account and all).

The hard part is that in a lot of cases where this happens, we'd just be causing a -lot- of rendering artifacts and an unusable browser (not this particular situation though), in those cases you'd probably rather crash than be really bad. I'm not sure I agree with the severity critical, since this is obviously malicious code that can't actually be exploited in anyway, but that's not too important.

FWIW I think with the particular case in this bug, we'd be better off catching this earlier  and implementing a fix somewhere else. We should probably avoid ever wanting to create such ridiculously big surfaces most likely :).
Flags: needinfo?(bas)

Comment 14

5 years ago
(In reply to Bas Schouten (:bas.schouten) from comment #13)
> FWIW I think with the particular case in this bug, we'd be better off
> catching this earlier  and implementing a fix somewhere else. We should
> probably avoid ever wanting to create such ridiculously big surfaces most
> likely :).

Given we have a reproducible case here, can we work on that approach? Who would do the work?
Flags: needinfo?(bas)
Keywords: reproducible
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #14)
> (In reply to Bas Schouten (:bas.schouten) from comment #13)
> > FWIW I think with the particular case in this bug, we'd be better off
> > catching this earlier  and implementing a fix somewhere else. We should
> > probably avoid ever wanting to create such ridiculously big surfaces most
> > likely :).
> 
> Given we have a reproducible case here, can we work on that approach? Who
> would do the work?

I'm not sure what the right place for that is? It could be at the window.open level, in which case presumably it's some sort of DOM thing? Or it would be restricted at the widget level maybe? I don't know too much about those parts of our codebase.
Flags: needinfo?(bas)

Comment 16

5 years ago
Benjamin, who can we bring in here to address those questions Bas is asking here?
Flags: needinfo?(benjamin)
We should probably implement reasonable restrictions at both the DOM and widget layers. Kairo can you file those as separate blocking bugs?
Flags: needinfo?(benjamin)

Updated

5 years ago
Depends on: 1029124

Updated

5 years ago
Depends on: 1029125

Comment 18

5 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #17)
> We should probably implement reasonable restrictions at both the DOM and
> widget layers. Kairo can you file those as separate blocking bugs?

Filed bug 1029124 and bug 1029125, but given that my info on the engineering side of this is extremely limited, I couldn't put much info into those bugs, please help there on getting the right info there and get them assigned to the right people.
See Also: → 1048619
See Also: → 1045588
Duplicate of this bug: 1108342

Updated

4 years ago
Crash Signature: [@ gfxContext::PushClipsToDT(mozilla::gfx::DrawTarget*) ] → [@ gfxContext::PushClipsToDT(mozilla::gfx::DrawTarget*) ] [@ gfxContext::PushClipsToDT ]
Version: unspecified → 29 Branch
This crash reproduces for me in Firefox 29.0.1 but on Firefox 47.0.1. Please reopen if this still reproduces for you.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #20)
> This crash reproduces for me in Firefox 29.0.1 but on Firefox 47.0.1. Please
> reopen if this still reproduces for you.

Sorry, I mean reproduces in Firefox 29.0.1, *not* in Firefox 47.0.1 (ie. this no longer reproduces for me).
You need to log in before you can comment on or make changes to this bug.