1583382 - Crash in [@ @0x0 | HeapLock]

Status: RESOLVED WORKSFORME

(External Software Affecting Firefox :: Other, defect, P3)

Description

[[:philipp]]

This bug is for crash report bp-751d7356-1412-4c0d-83a6-e6d8e0190923.

Top 10 frames of crashing thread:

0  @0x0 
1 kernelbase.dll HeapLock 
2 xul.dll nsresult SystemHeapReporter::CollectReports xpcom/base/nsMemoryReporterManager.cpp:1060
3 xul.dll nsresult mozilla::detail::RunnableFunction<`lambda at z:/task_1566861941/build/src/xpcom/base/nsMemoryReporterManager.cpp:1863:7'>::Run xpcom/threads/nsThreadUtils.h:564
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1225
5 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
6 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:88
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
9 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

this browser crash signature is rising in numbers since the firefox 69 release. it's predominantly hitting users on 32bit versions of the browser on windows 7 and russian builds.

manually inspecting a handful of crash reports, they all show a randomly named alleged .dat file hooking into the browser process - so i assume this is a crash caused by malware on a user's system and am unsure if there's anything actionable for us here.

Comment 1

[Marcia Knous [:marcia]]

Discussed during triage. Marking as fix optional for 69.

Comment 2

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

The priority flag is not set for this bug.
:marcia, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Marcia Knous [:marcia]]

Marking as a P3. Here are the addon correlations:

91.67% in signature vs 02.63% overall) reason = EXCEPTION_ACCESS_VIOLATION_EXEC
(94.44% in signature vs 07.28% overall) Addon "[e-mail]" = true
(94.44% in signature vs 07.30% overall) Addon "[e-mail]" = true
(94.44% in signature vs 07.30% overall) Addon "[e-mail]" = true
(94.44% in signature vs 07.89% overall) Addon "[e-mail]" = true

Comment 4

[Toshihito Kikuchi [:toshi]]

I analyzed a couple of the dumps. In ntdll!RtlLockHeap, the process went to the branch for PageHeap because of the flag state in the heap structure. In a normal case, the process calls to verifier!AVrfDebugPageHeapLock, but in the dump verifier.dll was not loaded, thus it jumps to null. This crash will not happen if CFG is on. So the same issue on Win10 may be reported as a different signature.

I have no idea why the flag in the heap structure was turned on without loading verifier.dll.

Comment 5

[(No longer employed by Mozilla) Aaron Klotz]

ImageFileExecutionOptions?

Comment 6

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

Closing because no crashes reported for 12 weeks.