Crash in [@ mozilla::freestanding::patched_NtMapViewOfSection | BasepLoadLibraryAsDataFileInternal]
Categories
(Firefox :: Launcher Process, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox89 | --- | wontfix |
firefox90 | --- | fixed |
firefox91 | --- | fixed |
People
(Reporter: aryx, Assigned: toshi)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
Crash which started with Firefox 86, 220 crashes for that release cycle. The process uptime doesn't point to any startup issue. The correlations tab mentions several IMEs and antivirus DLLs being involved in the various crash reports.
Crash report: https://crash-stats.mozilla.org/report/index/bda196ce-11c8-404f-a07a-3054e0210402
Reason: EXCEPTION_ACCESS_VIOLATION_READ
Top 10 frames of crashing thread:
0 firefox.exe mozilla::freestanding::patched_NtMapViewOfSection browser/app/winlauncher/freestanding/DllBlocklist.cpp:435
1 kernelbase.dll BasepLoadLibraryAsDataFileInternal
2 kernelbase.dll LoadLibraryExW
3 tmmon64.dll tmmon64.dll@0x2fded
4 kernelbase.dll GetFileVersionInfoSizeExW
5 xul.dll mozilla::ModuleVersionInfo::GetFromImage toolkit/xre/ModuleVersionInfo.cpp:72
6 xul.dll mozilla::UntrustedModulesProcessor::GetOrAddModuleRecord toolkit/xre/UntrustedModulesProcessor.cpp:495
7 xul.dll mozilla::UntrustedModulesProcessor::ProcessModuleLoadQueue toolkit/xre/UntrustedModulesProcessor.cpp:615
8 xul.dll mozilla::UntrustedModulesProcessor::BackgroundProcessModuleLoadQueue toolkit/xre/UntrustedModulesProcessor.cpp:480
9 xul.dll mozilla::detail::RunnableMethodImpl< xpcom/threads/nsThreadUtils.h:1201
Assignee | ||
Comment 1•3 years ago
|
||
This is similar to bug 1702086: the mapped address was already unloaded whey we tried to parse it. However, it's strange because that unloading happened while we were still in patched_NtMapViewOfSection
.
I noticed all of these module loads came from GetFileVersionInfoW
in xul!mozilla::ModuleVersionInfo::GetFromImage
, where the module was loaded with LOAD_LIBRARY_AS_DATAFILE
and LOAD_LIBRARY_AS_IMAGE_RESOURCE
. In this case, the mapped address is not executable though the address type is MEM_IMAGE
. We don't have to look at the blocklist if the mapped address is non-executable.
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
When a module is loaded with LOAD_LIBRARY_AS_IMAGE_RESOURCE
, the mapped region
is MEM_IMAGE
, but it's not executable. We don't have to check the blocklist
in such a case.
Comment 4•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 5•3 years ago
|
||
The patch landed in nightly and beta is affected.
:toshi, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 6•3 years ago
|
||
Comment on attachment 9226622 [details]
Bug 1702717 - Skip blocklisting if the mappad region is not executable. r=mhowell
Beta/Release Uplift Approval Request
- User impact if declined: Firefox may crash if one of the blocked modules was loaded. This is a timing issue we could not reproduce.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The change is to loosen the condition to block a module i.e. we don't block a module from being mapped if it's not executable image mapping. More specifically, this patch adds one more condition to make an early return from our hook function, so the risk is low.
- String changes made/needed: None
Comment 7•3 years ago
|
||
Comment on attachment 9226622 [details]
Bug 1702717 - Skip blocklisting if the mappad region is not executable. r=mhowell
approved for 90.0b9
Comment 8•3 years ago
|
||
bugherder uplift |
Description
•