1934258 - Crash in [@ mozilla::ipc::IProtocol::FatalError | mozilla::dom::PContentParent::DeallocManagee] with Qihoo 360

Status: RESOLVED FIXED

(External Software Affecting Firefox :: Other, defect)

Description

[Donal Meehan [:dmeehan]]

Crash report: https://crash-stats.mozilla.org/report/index/396d6f9b-589f-451c-a68f-e9ec90241129

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  mozilla::ipc::IProtocol::FatalError(char const* const)  ipc/glue/ProtocolUtils.cpp:394
0  xul.dll  mozilla::dom::PContentParent::DeallocManagee(int, mozilla::ipc::IProtocol*)  ipc/ipdl/PContentParent.cpp:6357
1  xul.dll  PLDHashTable::ComputeKeyHash(void const*) const  xpcom/ds/PLDHashTable.cpp:479
1  xul.dll  PLDHashTable::Search(void const*) const  xpcom/ds/PLDHashTable.cpp:499
2  chromesafe64.dll  chromesafe64.dll@0x20ae6
3  ntdll.dll  RtlSetLastWin32Error
4  ?  @0x00000156baef0b0f
5  xul.dll  _tailMerge_hid.dll
6  chromesafe64.dll  chromesafe64.dll@0x22bb0
7  chromesafe64.dll  chromesafe64.dll@0x2ae03

Comment 1

[Donal Meehan [:dmeehan]]

:jld could this be triaged? Not sure what introduced this in 128.5esr

Comment 2

[Yannis Juglaret [:yannis]]

Changing components because all crash reports have chromesafe64.dll from Beijing Qihu Technology Co., Ltd. in stack.

Comment 3

[Greg Stoll :gstoll]

Windows DLLBlocklist request form

1. How were we aware of the problem?
   Topcrasher in ESR (but seemingly no crashes in release/beta/nightly)

2. What is a suspicious product causing the problem?
   Qihoo 360 Total Security by Beijing Qihu Technology Co., Ltd.

3. Is the product downloadable? If so, do we have a local repro?
   No, as far as I can tell.

4. Which OS versions does the problem occur on?
   Windows 10 and 11.

5. Which process types does the problem occur on?
   Just the browser process.

6. What is the maximum version of the module in the crash reports?
   According to telemetry the maximum version that crashes is 2.0.0.26.

7. Is the issue fixed by a newer version of the product?
   It looks like there are newer versions being used in ESR that do not crash, so possibly.

8. Do we have data about the module in the third-party-module ping?
   Yes

9. Do we know how the module is loaded?
   Looks safe to block.

10. Describe your conclusion.
    We should block chromesafe64.dll versions 2.0.0.26 and earlier in the browser process in ESR only.

Comment 4

[Greg Stoll :gstoll]

Attachment: Bug 1934258 - block chromesafe64.dll on ESR

Comment 5

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/21def3e05184

Comment 6

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/f2cc51880bf4

Comment 7

[Donal Meehan [:dmeehan]]

Merged in esr128 and an esr128.5 branch