1504527 - Crash in mozilla::net::LoadInfo::Release

Status: RESOLVED DUPLICATE of bug 1045992

(Core :: DOM: Core & HTML, defect)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-a860d6cb-cbd1-464d-9b72-ef3ea0181028.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll mozilla::net::LoadInfo::Release netwerk/base/LoadInfo.cpp:577
1 xul.dll mozilla::dom::DeferredFinalizerImpl<nsISupports>::DeferredFinalize dom/bindings/BindingUtils.h:2937
2 xul.dll mozilla::IncrementalFinalizeRunnable::ReleaseNow xpcom/base/CycleCollectedJSRuntime.cpp:1388
3 xul.dll mozilla::IncrementalFinalizeRunnable::Run xpcom/base/CycleCollectedJSRuntime.cpp:1424
4 xul.dll IdleRunnableWrapper::Run xpcom/threads/nsThreadUtils.cpp:343
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1161
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:519
7 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:97
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:318
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:298

=============================================================

this crash signature has been around for a while but seems to be somewhat increasing in frequency since firefox 63.
a number of crash reports indicate a uaf problem.

Comment 1

[Daniel Veditz [:dveditz]]

There were scattered crashes in this function before 63, but UAFs and the stack in comment 0 seems new in 63. Let's try networking first because it's LoadInfo, but it could be a change in the way DOM references it.

Comment 2

[Dragana Damjanovic [:dragana]]

Nathan, I am not sure how CycleCollectedJSRuntime works, may i ask you to take a quick look?

Comment 3

[Andrew McCreight [:mccr8]]

When a JS object is holding onto a C++ object, and the JS object is going away, we don't want to call Release() on the C++ object while we're in the middle of the GC. Instead, the C++ object gets added to the deferred finalize array, and we call release after the GC is done.

The stack suggests that the LoadInfo object was destroyed in between when we added it to the deferred finalize array and when do the release. This suggests there may be some refcounting bug with LoadInfo, or maybe something destroys the LoadInfo directly.

Alternatively, we have had problems in the past with UAFs where the UAF is in the deferred finalize array itself that we've spent a fair amount of time looking at with no success. It looks like the rax register is the poison value, so maybe this means that |this| is poisoned, and thus the finalizer array itself was destroyed? I'm not sure how to interpret that. It would seem odd that these crashes would all end up bucketed as LoadInfo, but maybe LTO is doing something clever.

Comment 4

[Andrew McCreight [:mccr8]]

This feels like a variant of bug 1045992, but there are other Windows crashes in 63.0.1 so maybe it can't be a strict signature change.

Comment 5

[Dragana Damjanovic [:dragana]]

(In reply to Andrew McCreight [:mccr8] from comment #4)
> This feels like a variant of bug 1045992, but there are other Windows
> crashes in 63.0.1 so maybe it can't be a strict signature change.

yes this looks like bug 1045992

Comment 6

[Daniel Stenberg [:bagder]]

I'll be a bit blunt and say that this looks rather like a DOM issue, especially with the resemblance to bug 1045992 which already is marked as such.

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

This is a duplicate of  unhidden crash bug 1045992, which is marked as P5. We might want to change the priority since there is a security issue here. Hsin-Yi, can you help find an owner for bug 1045992?

Comment 9

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #8)
> This is a duplicate of  unhidden crash bug 1045992, which is marked as P5.
> We might want to change the priority since there is a security issue here.
> Hsin-Yi, can you help find an owner for bug 1045992?

Let me work on this. I'll get back here, very likely after the holidays.

Comment 10

[Andrew McCreight [:mccr8]]

I've spent some time trying to fix that crash, but we have no test case so it is hard to know what to do.