1701791 - Invalid Win32k use in content process [xul!mozilla::image::IOThreadIniter::Run]

Status: RESOLVED FIXED

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

Description

[Chris Martin [:cmartin] - PTO back Sept 22]

COM is initialized here

Call stack:

win32u!NtUserGetThreadState
USER32!LoadIcoCur+0x1db
USER32!RegisterIMEClass+0x9f
USER32!VerNtUserCreateWindowEx+0x26f
USER32!CreateWindowInternal+0x1a4
USER32!CreateWindowExW+0x82
combase!InitMainThreadWnd+0x57 [onecore\com\combase\objact\mainthrd.cxx @ 148]
combase!ThreadFirstInitialize+0x213 [onecore\com\combase\class\compobj.cxx @ 3460]
combase!_CoInitializeEx+0x1d0 [onecore\com\combase\class\compobj.cxx @ 3745]
combase!CoInitializeEx+0x58 [onecore\com\combase\class\compobj.cxx @ 3835]
xul!mozilla::image::IOThreadIniter::Run+0xc [c:\moz\mozilla-central\image\DecodePool.cpp @ 82]
xul!nsThread::ProcessNextEvent+0x964 [c:\moz\mozilla-central\xpcom\threads\nsThread.cpp @ 1149]
xul!NS_ProcessNextEvent+0x65 [c:\moz\mozilla-central\xpcom\threads\nsThreadUtils.cpp @ 548]
xul!mozilla::ipc::MessagePumpForNonMainThreads::Run+0xb6 [c:\moz\mozilla-central\ipc\glue\MessagePump.cpp @ 303]
xul!MessageLoop::RunInternal+0x16 [c:\moz\mozilla-central\ipc\chromium\src\base\message_loop.cc @ 335]
xul!MessageLoop::RunHandler+0x50 [c:\moz\mozilla-central\ipc\chromium\src\base\message_loop.cc @ 329]
xul!MessageLoop::Run+0x58 [c:\moz\mozilla-central\ipc\chromium\src\base\message_loop.cc @ 311]
xul!nsThread::ThreadFunc+0xed [c:\moz\mozilla-central\xpcom\threads\nsThread.cpp @ 393]
nss3!_PR_NativeRunThread+0x147 [c:\moz\mozilla-central\nsprpub\pr\src\threads\combined\pruthr.c @ 421]
nss3!pr_root+0x11 [c:\moz\mozilla-central\nsprpub\pr\src\md\windows\w95thred.c @ 140]
ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x42
KERNEL32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

Comment 1

[Bob Owen (:bobowen) (PTO until 17th Oct)]

https://treeherder.mozilla.org/jobs?repo=try&revision=43cf6fd470a5f7d966ce5c7764de5a95fcf5cf8d

Comment 2

[Bob Owen (:bobowen) (PTO until 17th Oct)]

Attachment: Bug 1701791 p1: Don't enable win32k lockdown for the file content process. r=handyman!

Win32k is required for moz-icon in the file content process and we don't want to
block enabling for web content processes on this and other uses that may only be
in the file content process.

Comment 3

[Bob Owen (:bobowen) (PTO until 17th Oct)]

Attachment: Bug 1701791 p2: Don't initialize COM on the image IO thread when win32k is locked down. r=gijs!

COM is required for calls to SHGetFileInfo for moz-icon, but we only currently
require that for the file content process. We may want to use it in the future
for the privileged about content process, in which case we will have to forgo
win32k lockdown there unless moz-icon is remoted.

Depends on D112960

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f62e0e4073bd
p1: Don't enable win32k lockdown for the file content process. r=handyman
https://hg.mozilla.org/integration/autoland/rev/fb5037e7bf9b
p2: Don't initialize COM on the image IO thread when win32k is locked down. r=tnikkel

Comment 5

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/f62e0e4073bd
https://hg.mozilla.org/mozilla-central/rev/fb5037e7bf9b