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

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.

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

(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.

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.

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?

need-contact@mozilla.com recommended secure@microsoft.com http://technet.microsoft.com/en-us/security/ff852094 I can contact them but I need help with the content.

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

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

vishalch@microsoft.com from Microsoft has been added to the list of CC.

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 ?

(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.

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.

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. ----

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

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

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.

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.

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

(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.

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