1026074 - startup crash for _VEC_memzero | TextStageManager::MapTextureTransferSurface(D2D_RECT_U const&, unsigned char**, unsigned int*)

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Liz Henry (:lizzard) (relman/hg->git project)]

This is the #4 topcrash for Firefox 31.0b1 for the last 7 days. Most are at startup. The crash signature is marked as high exploitability. 

https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2014-06-16&signature=_VEC_memzero+|+TextStageManager%3A%3AMapTextureTransferSurface%28D2D_RECT_U+const%26%2C+unsigned+char**%2C+unsigned+int*%29&version=Firefox%3A31.0b#tab-bugzilla

crashing thread for https://crash-stats.mozilla.com/report/index/af44642d-16d4-4b15-8379-bc1a92140612: 

0 	msvcrt.dll 	_VEC_memzero 	
1 	d2d1.dll 	TextStageManager::MapTextureTransferSurface(D2D_RECT_U const &,unsigned char * *,unsigned int *) 	
2 	d2d1.dll 	TextStageManager::AddStagesForSubrect(IDWritePrivateGlyphRunAnalysis *,SubRectInfo const *) 	
3 	d2d1.dll 	HwGlyphRunRealizer::IssueRenderingCommands(BatchedBrush *) 	
4 	d2d1.dll 	CHwSurfaceRenderTarget::DrawGlyphRunInternal(D2D_POINT_2F,DWRITE_GLYPH_RUN const *,BatchedBrush *,DWRITE_MEASURING_MODE) 	
5 	d2d1.dll 	CCommand_DrawGlyphRun::Execute(CBaseRenderTarget *) 	
6 	d2d1.dll 	CHwSurfaceRenderTarget::ProcessBatch(CBatch *) 	
7 	d2d1.dll 	CBatchSerializer::FlushInternal() 	
8 	d2d1.dll 	DrawingContext::FlushBatch() 	
9 	d2d1.dll 	DrawingContext::Flush(unsigned __int64 *,unsigned __int64 *) 	
10 	d2d1.dll 	D2DRenderTargetBase<ID2D1HwndRenderTarget>::Flush(unsigned __int64 *,unsigned __int64 *) 	
11 	xul.dll 	mozilla::gfx::DrawTargetD2D::Flush() 	gfx/2d/DrawTargetD2D.cpp
12 	xul.dll 	gfxContext::~gfxContext() 	gfx/thebes/gfxContext.cpp
13 	xul.dll 	xul.dll@0x141010 	
14 	xul.dll 	xul.dll@0x141010 	
15 	xul.dll 	mozilla::layers::ThebesLayerD3D10::DrawRegion(nsIntRegion &,mozilla::layers::SurfaceMode) 	gfx/layers/d3d10/ThebesLayerD3D10.cpp
16 	xul.dll 	mozilla::layers::ThebesLayerD3D10::Validate(mozilla::layers::ReadbackProcessor *) 	gfx/layers/d3d10/ThebesLayerD3D10.cpp
17 	xul.dll 	mozilla::layers::ContainerLayerD3D10::Validate() 	gfx/layers/d3d10/ContainerLayerD3D10.cpp
18 	xul.dll 	mozilla::layers::LayerManagerD3D10::Render(mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/d3d10/LayerManagerD3D10.cpp
19 	xul.dll 	mozilla::layers::LayerManagerD3D10::EndTransaction(void (*)(mozilla::layers::ThebesLayer *,gfxContext *,nsIntRegion const &,mozilla::layers::DrawRegionClip,nsIntRegion const &,void *),void *,mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/d3d10/LayerManagerD3D10.cpp
20 	xul.dll 	nsDisplayList::PaintForFrame(nsDisplayListBuilder *,nsRenderingContext *,nsIFrame *,unsigned int) 	layout/base/nsDisplayList.cpp
21 	xul.dll 	nsLayoutUtils::PaintFrame(nsRenderingContext *,nsIFrame *,nsRegion const &,unsigned int,unsigned int) 	layout/base/nsLayoutUtils.cpp
22 	xul.dll 	PresShell::Paint(nsView *,nsRegion const &,unsigned int) 	layout/base/nsPresShell.cpp
23 	xul.dll 	nsViewManager::ProcessPendingUpdatesPaint(nsIWidget *) 	view/src/nsViewManager.cpp
24 	xul.dll 	nsViewManager::ProcessPendingUpdatesForView(nsView *,bool) 	view/src/nsViewManager.cpp
25 	xul.dll 	nsViewManager::ProcessPendingUpdates() 	view/src/nsViewManager.cpp

Comment 1

[u279076]

See also bug 988549. I raised this as a concern in the crashkill meeting today and Benjamin didn't think filing a security bug would be of any benefit to getting it resolved. I'll leave it to engineering to decide whether we should dupe this though.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Bas, does this help us with bug 988549 at all?

Comment 3

[Bas Schouten (:bas.schouten)]

(In reply to Milan Sreckovic [:milan] from comment #2)
> Bas, does this help us with bug 988549 at all?

Not really, the stack we see here is a generic painting stack. It's what we'd 'expect' to see above the stack in bug 988549. That in itself is nice to see confirmed, but it contributes in no way to getting STR or fixing it.

Comment 4

[Daniel Veditz [:dveditz]]

Given the access violation write I concur with the !exploitable "high" rating, but this looks like a bug in either windows or the graphics drivers. We should report this to MS.

Comment 5

[Robert Kaiser]

According to bug 988549 comment #34, this is happening with very old drivers. As this is on Win7 and Win8 and AFAIK MS is even pushing updates to drivers via their update process, I think the comment #4 idea of reporting to MS is good, esp. as this might be a driver-caused Windows security issue.

Release Managers, do we have a good avenue of communication to MS for things like this?

Comment 6

[Sylvestre Ledru [:Sylvestre]]

[e-mail] recommended [e-mail]
http://technet.microsoft.com/en-us/security/ff852094

I can contact them but I need help with the content.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Daniel, do you think you could help me to draft an email to MS?

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Mail Sent. Nicolas Silva helped me with the wording. Let see what happens next.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

[e-mail] from Microsoft has been added to the list of CC.

Comment 10

[Vishal Chauhan]

Hi, I am security engineer from Microsoft working on this case. 
Can someone help me get to the RawDump from the crash report: https://crash-stats.mozilla.com/report/index/af44642d-16d4-4b15-8379-bc1a92140612 ?

Comment 11

[Robert Kaiser]

(In reply to Vishal Chauhan from comment #10)
> Hi, I am security engineer from Microsoft working on this case. 

I think handing out raw dumps is hard due to privacy issues (raw dumps contain raw memory of our users). That said, the core issue here is that apparently a lot of our Windows users are still using old Intel drivers that are known to have security and stability issues around D2D usage. We wonder if Microsoft can help to get them to fixed drivers, which would help security and stability at the same time.

Comment 12

[Vishal Chauhan]

Thanks Robert for the insight and quick turnaround. 
We at MS are on the same conclusion based on the stack and the internal dumps we have on similar looking issue, but just wanted to double check before calling out the older Intel driver. I understand the privacy concern, so we will go ahead with the current findings as conclusive.
I am not sure how we push updated 3rd party drivers, but if we have a channel, we will try pursuing it. You will probably get more details from the PM whom you initially got in touch with. Thanks.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

We received this email two days ago, confirming comment #12:
---- 
We've completed our investigation on this issue and have identified it as belonging to a third party driver for which we do not control the codebase. Thanks for bringing this to our attention and we look forward to working with you in the future. 
----

Comment 14

[u279076]

This is no longer a topcrash.

Reports for the last week:
Firefox 40: 30
Firefox 41: 51
Firefox 42:  4
Firefox 43:  0
Firefox 44:  0

Reports for the last month:
Firefox 40: 229
Firefox 41:  87
Firefox 42:   8
Firefox 43:   1
Firefox 44:   0

Comment 15

[u279076]

This crash remains but at low volume and appears to be a larger issue on ESR than Release. Firefox 38.7.1esr has the most crashes with 60 reports over the last week, compare to Firefox 45.0.2 with 39 reports over the same period. We also see 12 reports in the Firefox 46 beta builds but nothing for Aurora or Nightly.

Top Devices:
43.2% Intel 3rd Gen Core Graphics (0x0166, 0x0152)
28.4% Intel 2nd Gen Core Graphics (0x0126)
 7.1% Intel 1st Gen Core Graphics (0x0046)

This looks to be mostly in older Intel graphics driver versions with the most recent version reported being 9.17.10.4101 (nearly a year old at this point).

Can we escalate this to Intel? Can we work around this in our code somehow? If not, is there a point in keeping this bug report open?

Thanks

Comment 16

[u279076]

We're still seeing ~20 crashes reported per day on average, none of which are on current driver versions. If this can't be fixed (as seems to be indicated by comment 13) can we prevent this crash from occurring with a block? Otherwise I see no other option than to close this bug as wontfix.

Comment 17

[Milan Sreckovic [:milan] (needinfo for best results)]

I will take a look, but just because we don't have a path forward, doesn't mean we should close it; there is a loss of information once we close as wontfix, and it's expensive to find bugs.

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

See also bug 635464.  Don't want to "see also" as a link, so that it doesn't point back to a sec bug.

Comment 19

[u279076]

(In reply to Milan Sreckovic [:milan] from comment #17)
> I will take a look, but just because we don't have a path forward, doesn't
> mean we should close it; there is a loss of information once we close as
> wontfix, and it's expensive to find bugs.

Any progress? This crash is still being reported in current versions.

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

Work is in bug 635464; some more information, not necessarily closer to a fix.

Comment 21

[Brad Werth [:bradwerth]]

No longer actionable, and probably fixed by driver updates sometime in the last several years.