Closed Bug 1702717 Opened 4 months ago Closed 2 months ago

Crash in [@ mozilla::freestanding::patched_NtMapViewOfSection | BasepLoadLibraryAsDataFileInternal]


(Firefox :: Launcher Process, defect)

Windows 10



91 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox89 --- wontfix
firefox90 --- fixed
firefox91 --- fixed


(Reporter: aryx, Assigned: toshi)




(Keywords: crash, regression)

Crash Data


(1 file)

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:


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

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.

Assignee: nobody → tkikuchi
Regressed by: 1686229

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.

Pushed by
Skip blocklisting if the mappad region is not executable.  r=mhowell
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch

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.

Flags: needinfo?(tkikuchi)

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
Flags: needinfo?(tkikuchi)
Attachment #9226622 - Flags: approval-mozilla-beta?

Comment on attachment 9226622 [details]
Bug 1702717 - Skip blocklisting if the mappad region is not executable. r=mhowell

approved for 90.0b9

Attachment #9226622 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.