1718414 - Crash in [@ DdQueryDisplaySettingsUniqueness]

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect, P2)

Description

[u673061]

Maybe Fission related. (DOMFissionEnabled=1)
Steps to reproduce:
I was trying to upload a profile picture to my Youtube channel, but after I selected the file, the tab suddenly crashed.

Crash report: https://crash-stats.mozilla.org/report/index/4c9e2516-408c-4145-a251-2b93e0210626

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 gdi32.dll DdQueryDisplaySettingsUniqueness 
1 dxgi.dll long CDXGIFactory::SampleAdapters 
2 dxgi.dll long CDXGIFactory::Initialize 
3 dxgi.dll long CreateDXGIFactoryImpl 
4 dxgi.dll long CreateDXGIFactoryActualImpl1 
5 dxgi.dll CreateDXGIFactory1 
6 xul.dll mozilla::gfx::DeviceManagerDx::GetDXGIAdapter gfx/thebes/DeviceManagerDx.cpp:499
7 xul.dll mozilla::gfx::DeviceManagerDx::CreateContentDevice gfx/thebes/DeviceManagerDx.cpp:801
8 xul.dll mozilla::gfx::DeviceManagerDx::CreateContentDevices gfx/thebes/DeviceManagerDx.cpp:477
9 xul.dll gfxWindowsPlatform::InitializeD3D11 gfx/thebes/gfxWindowsPlatform.cpp:1453

Comment 1

[u673061]

Oops.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Text' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Permanent crash with Windows win32k Lockdown enabled (which is exposed to the user from Settings > Nightly Experiments).

Comment 4

[Chris Peterson [:cpeterson]]

Bug 1698732 (now fixed?) was another win32k lockdown crash in DdQueryDisplaySettingsUniqueness.

Comment 5

[u673061]

The severity and priority fields of this bug are not set, would somebody please set them?

Comment 6

[u673061]

The crash still happens on the lastest Nightly (92.0a1) on July 12 2021.

Comment 7

[u608768]

We're seeing a lot of these in recent Nightlies. gcp, something be done here?

Comment 8

[u673061]

By the way the severity should not be N/A. It should be defined as S1 or S2 because it is quite serious and frequent.

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

David: This crash should only happen with the experimental win32k lockdown enabled. Go into Settings > Nightly Experiments > "Win32k Lockdown" at the end of the list and disable it.

Comment 10

[Gian-Carlo Pascutto [:gcp]]

We're seeing a lot of these in recent Nightlies. gcp, something be done here?

Expected as we're dogfooding win32k lockdown. Needinfo cmartin if this is a known issue from another bug or a new problem found through the dogfooding.

It should be defined as S1 or S2 because it is quite serious and frequent.

We're not shipping win32k lockdown by default (hence no S1/S2) due to known and unknown issues, this is one of them. Thanks for helping us find it!

Comment 11

[u673061]

Still happening on Firefox Nightly 93.0a1.

Comment 12

[Chris Martin [:cmartin]]

Whoops didn't mean to leave the NI on this bug so long.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Any news on this, Chris?

Comment 14

[Chris Martin [:cmartin]]

Indeed -- I'm testing a fix out right now. Should be available shortly.

Comment 15

[Chris Martin [:cmartin]]

Attachment: Bug 1718414 - Stop canvas from initializing D3D in locked-down content process when GPU process fails

Before Win32k Lockdown, Canvas would ensure that it would get the fastest possible implementation by initializing
devices in content process before allocating persistent buffers for its backing.

However, with Win32k Lockdown it's no longer possible, as initializing Direct3D and Direct2D make Win32k calls that
crash the locked-down content process.

This issue is generally solved by Remote Canvas; however, Remote Canvas is disabled if the GPU process is disabled.
If that happens, the current behavior is to attempt to initialize hardware acceleration again, causing a crash when
Win32k Lockdown is in effect.

This patch changes the behavior so that the devices will not initialize if they are in a locked-down content process,
even if Remote Canvas is disabled. The effect is that Canvas will fall back to using Skia for everything.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4ad22daf744b
Stop canvas from initializing D3D in locked-down content process when GPU process fails r=sotaro,bobowen

Comment 17

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/4ad22daf744b

Comment 18

[Gabriele Svelto [:gsvelto]]

This is still happening but with a slightly different stack trace, here's an example 6e7f8b59-1fb3-4884-9c6f-859180220120:

0 gdi32.dll DdQueryDisplaySettingsUniqueness 
1 dxgi.dll long CDXGIFactory::SampleAdapters 
2 dxgi.dll long CDXGIFactory::Initialize 
3 dxgi.dll long CreateDXGIFactoryImpl 
4 dxgi.dll long CreateDXGIFactoryActualImpl 
5 dxgi.dll CreateDXGIFactory 
6 amdh264enc64.dll <unknown in amdh264enc64.dll> 
7 amdh264enc64.dll <unknown in amdh264enc64.dll> 
8 amdh264enc64.dll <unknown in amdh264enc64.dll> 
9 amdh264enc64.dll <unknown in amdh264enc64.dll> 

And here's another one c5b9e7b8-d214-4a92-a798-ed1340220119:

0 gdi32.dll DdQueryDisplaySettingsUniqueness 
1 dxgi.dll long CDXGIFactory::SampleAdapters 
2 dxgi.dll long CDXGIFactory::Initialize 
3 dxgi.dll long CreateDXGIFactoryImpl 
4 dxgi.dll long CreateDXGIFactoryActualImpl 
5 dxgi.dll CreateDXGIFactory 
6 mfx_mft_h264ve_64.dll <unknown in mfx_mft_h264ve_64.dll> 
7 mfx_mft_h264ve_64.dll <unknown in mfx_mft_h264ve_64.dll> 
8 mfx_mft_h264ve_64.dll <unknown in mfx_mft_h264ve_64.dll> 
9 mfx_mft_h264ve_64.dll <unknown in mfx_mft_h264ve_64.dll> 

There is another difference that's probably relevant. The old crashes had the value of GetLastError() set to STATUS_FILE_LOCKED_WITH_ONLY_READERS, the new ones always have ERROR_TOO_MANY_POSTS instead.

Comment 19

[Chris Martin [:cmartin]]

Thanks :gsvelto! I reopened the ticket. This is definitely a different stack trace that leads to the same API call, so I'll have to investigate this further.

Comment 20

[Gian-Carlo Pascutto [:gcp]]

Let's open a new bug for these.