1284819 - Crash in mozilla::dom::indexedDB::PIndexedDBPermissionRequestChild::DestroySubtree

Status: RESOLVED DUPLICATE of bug 1314318

(Core :: Graphics: Layers, defect)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is 
report bp-4e9f9530-f824-403b-a567-46bc52160706.
=============================================================
Crashing Thread (22)
Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::dom::indexedDB::PIndexedDBPermissionRequestChild::DestroySubtree(mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::ActorDestroyReason) 	obj-firefox/ipc/ipdl/PImageContainerChild.cpp:287
1 	xul.dll 	mozilla::layers::PImageBridgeChild::DestroySubtree(mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::ActorDestroyReason) 	obj-firefox/ipc/ipdl/PImageBridgeChild.cpp:1023
2 	xul.dll 	mozilla::layers::PImageBridgeChild::OnChannelClose() 	obj-firefox/ipc/ipdl/PImageBridgeChild.cpp:911
3 	xul.dll 	mozilla::ipc::MessageChannel::NotifyChannelClosed() 	ipc/glue/MessageChannel.cpp:2224
4 	xul.dll 	mozilla::layers::ImageBridgeShutdownStep2 	gfx/layers/ipc/ImageBridgeChild.cpp:303
5 	xul.dll 	RunnableFunction<void (*)(mozilla::layers::ImageBridgeChild*, mozilla::layers::ImageBridgeParent*), mozilla::Tuple<mozilla::layers::ImageBridgeChild*, mozilla::layers::ImageBridgeParent*> >::Run() 	ipc/chromium/src/base/task.h:338
6 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc:444
7 	nss3.dll 	_MD_CURRENT_THREAD 	nsprpub/pr/src/md/windows/w95thred.c:317
8 	xul.dll 	base::MessagePumpDefault::Run(base::MessagePump::Delegate*) 	ipc/chromium/src/base/message_pump_default.cc:34
9 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:223
10 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:203
11 	xul.dll 	base::Thread::ThreadMain() 	ipc/chromium/src/base/thread.cc:174

this crash signature seems to increase in volume since the 48 beta cycle, currently it is making up 0.13% of 48.0b5 browser crashes.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Uh, why is PImageBridgeChild::DestroySubtree() calling PIndexedDBPermissionRequestChild::DestroySubtree().  Those seem unrelated.  I wonder if this stack is corrupted.

Comment 2

[[:philipp]]

most crash reports with this signature have a similar stacktrace: https://crash-stats.mozilla.com/search/?signature=%3Dmozilla%3A%3Adom%3A%3AindexedDB%3A%3APIndexedDBPermissionRequestChild%3A%3ADestroySubtree&_facets=proto_signature

Comment 3

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

Crash volume for signature 'mozilla::dom::indexedDB::PIndexedDBPermissionRequestChild::DestroySubtree':
 - nightly (version 50): 0 crash from 2016-06-06.
 - aurora  (version 49): 2 crashes from 2016-06-07.
 - beta    (version 48): 350 crashes from 2016-06-06.
 - release (version 47): 22 crashes from 2016-05-31.
 - esr     (version 45): 0 crash from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          0          0          0          0          0          0
 - aurora           0          0          0          1          0          1          0
 - beta             1          8        121        153         32         26          7
 - release          9          6          1          3          0          0          0
 - esr              0          0          0          0          0          0          0

Affected platform: Windows

Comment 4

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

Crash volume for signature 'mozilla::dom::indexedDB::PIndexedDBPermissionRequestChild::DestroySubtree':
 - nightly (version 51): 0 crashes from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 42 crashes from 2016-08-02.
 - release (version 48): 216 crashes from 2016-07-25.
 - esr     (version 45): 3 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       0       0       0
 - aurora        0       0       0
 - beta         26      15       0
 - release       0       0       0
 - esr           1       0       1

Affected platform: Windows

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora
 - beta    #2689
 - release #133
 - esr     #5016

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Shutdown crash, while shutting down IPC  ImageBridgeClient, with consistent UAF signature.  High frequency (200+/day), spiked around 8/25 or so (right around the time of that bot report).

It appears that DestroySubtree() is calling Unregister(mId) (inlined probably), and mManager is a UAF.  Or perhaps 'this' is UAF (came from kids[i] in PImageBridgeChild::DestroySubtree()).

CCing relevant folk - baku, any thoughts?


sec-high since it's harder to exploit shutdown UAFs

Comment 6

[Marcia Knous [:marcia]]

Tracking 52+ for this sec high bug.

Comment 7

[Gerry Chang [:gchang]]

Un-track for 51 as no crashes found in 51 so far.

Comment 8

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Given that there isn't a fix in progress and that there are no occurrences of this crash in the past 7 days, untracking this one and tagging as wontfix for 50.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

No crashes ever in 49.0.*, 50, 51 or 52.  Last crashes were in 49.0b7ish.  Looks like it was fixed/uplifted.  48 has a bunch.  45esr has 4 crashes in the last 6ish weeks, but all are null-derefs, all in 45.3.0esr.  Since this spiked hard on Aug 25 with a UAF, this is different than the null-derefs.

The Null-derefs appear to be in PLayer*, while the UAFs appear to be in PImageBridge.  Also, the pImageBridge UAF was in 48b3/4/5 (maybe b7) back in ~June 26 onwards, then on ~Aug 25th which is apparently when 48.0.2 went out it spiked (there are no hits for 48.0 or 48.0.1, but they may not have gotten wide installation).  48.b1 showed 0xFFFFFFFFF crashes in PImageBridgeChild, but not clear UAFs.  Perhaps something uplifted to 48.b3ish.

Given this history and all remaining crashes are PLayer null-derefs, closing.

Comment 11

[Marco Castelluccio [:marco]]

I believe this is still happening, just changing signature from time to time (see bug 1314318 comment 9).