Crash nsPluginFrame::SetInstanceOwner

RESOLVED INCOMPLETE

Status

()

Core
Plug-ins
P3
critical
RESOLVED INCOMPLETE
6 years ago
10 months ago

People

(Reporter: Scoobidiver (away), Unassigned)

Tracking

(Blocks: 1 bug, 4 keywords)

13 Branch
All
Windows 7
crash, csectype-uaf, regression, sec-high
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s-, firefox13-, firefox46 wontfix, firefox47 wontfix, firefox49 wontfix, firefox-esr45 affected, firefox50 wontfix, firefox51 wontfix, firefox52 fix-optional, firefox53 affected, firefox54 affected)

Details

(crash signature)

(Reporter)

Description

6 years ago
It's a new crash signature that first appeared in 13.0a1/20120204.
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e777c939a3f9&tochange=766a59650976
It's likely a regression from bug 683059.

Signature 	nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*) More Reports Search
UUID	033d6628-f36a-423c-8603-2e4922120205
Date Processed	2012-02-05 07:50:48
Uptime	1050
Last Crash	23.0 hours before submission
Install Age	14.8 hours since version was first installed.
Install Time	2012-02-04 17:03:28
Product	Firefox
Version	13.0a1
Build ID	20120204031137
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7600
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 37 stepping 5
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x2fe8254a
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x9480, AdapterSubsysID: 04561028, AdapterDriverVersion: 8.783.3.0
D2D? D2D+
DWrite? DWrite+
D3D10 Layers? D3D10 Layers+
EMCheckCompatibility	True

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsObjectFrame::SetInstanceOwner 	layout/generic/nsObjectFrame.cpp:787
1 	xul.dll 	nsPluginInstanceOwner::Destroy 	dom/plugins/base/nsPluginInstanceOwner.cpp:2734
2 	xul.dll 	nsObjectLoadingContent::DoStopPlugin 	content/base/src/nsObjectLoadingContent.cpp:2036
3 	xul.dll 	nsObjectLoadingContent::StopPluginInstance 	content/base/src/nsObjectLoadingContent.cpp:2063
4 	xul.dll 	InDocCheckEvent::Run 	content/base/src/nsObjectLoadingContent.cpp:171
5 	xul.dll 	nsBaseAppShell::OnProcessNextEvent 	widget/xpwidgets/nsBaseAppShell.cpp:340
6 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:619
7 	nspr4.dll 	PR_Unlock 	nsprpub/pr/src/threads/combined/prulock.c:347
8 	xul.dll 	TimerThread::RemoveTimer 	xpcom/threads/TimerThread.cpp:435
9 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
10 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:201
11 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:175
12 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
13 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:258
14 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:220
15 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3537
16 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:107

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsObjectFrame%3A%3ASetInstanceOwner%28nsPluginInstanceOwner*%29
tracking-firefox13: --- → ?

Comment 1

6 years ago
This was discussed in the original bug. These are InDocCheckEvent::Run()'s firing off after nsObjectFrame's are gone. Once that problem gets tracked down and fixed these should go away.
(Reporter)

Comment 2

6 years ago
Crash reports contain jvm.dll (Java HotSpot(TM) Client VM) and it might be related to bug 285982 and bug 724248.

Updated

6 years ago
Blocks: 532972
(Reporter)

Comment 4

6 years ago
It's #6 top crasher in 13.0a1 over the last 3 days.
Keywords: topcrash
(Reporter)

Updated

6 years ago
Crash Signature: [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] → [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] [@ nsPresContext::GetRootPresContext()]
(Reporter)

Comment 5

6 years ago
One comment says:
"I was running the nVidia "About Your GPU" Java applet. Around 5 minutes ago, I ran the same applet and Firefox "Stopped Responding" for around 10 seconds."

Updated

6 years ago
tracking-firefox13: ? → +

Comment 6

6 years ago
These have gone way down in volume. I see only 4 crashes in the past 7 days. A few weeks ago we have 100 crashes. Maybe some 3rd party issue that's been fixed? I say we watch it for another week then remove the tracking flag.

Comment 7

6 years ago
The patch in bug 723523 probably improved the situation.
(Reporter)

Comment 8

6 years ago
It's no longer a top crasher for both signatures.
Keywords: topcrash

Comment 9

6 years ago
(In reply to Scoobidiver from comment #8)
> It's no longer a top crasher for both signatures.

Given that, untracking for release.
tracking-firefox13: + → -

Comment 10

6 years ago
Crash with bp-176c4339-affe-4583-9274-5ceec2120601
http://hg.mozilla.org/releases/mozilla-aurora/rev/91eca10ae9a5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120531 Firefox/14.0a2 ID:20120531042008

Updated

2 years ago
Crash Signature: [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] [@ nsPresContext::GetRootPresContext()] → [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] [@ nsPresContext::GetRootPresContext()] [@ nsObjectFrame::SetInstanceOwner] [@ nsPresContext::GetRootPresContext]

Comment 11

2 years ago
The crashes at nsPresContext::GetRootPresContext showed up in the e10s experiment as an e10s-only crash signature. These crashes are at poison + offset 0xe5e5e5ed so if this is the same bug it is a UAF and should block e10s.

Marking s-s for now.
Group: core-security
tracking-e10s: --- → ?

Comment 12

2 years ago
Link to the recent crashes: https://crash-stats.mozilla.com/search/?signature=~nsPresContext%3A%3AGetRootPresContext&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=address&_columns=reason#crash-reports

Updated

2 years ago
tracking-e10s: ? → m9+

Comment 13

2 years ago
jet can you help find an owner here? Investigating this is currently blocking e10s rollout.
Flags: needinfo?(bugs)

Comment 14

2 years ago
Sure, I can help. Is the original signature still relevant?
nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)

Or, are we only interested in hunting down ::GetRootPresContext()?
Flags: needinfo?(jmathies)

Comment 15

2 years ago
I wonder if this is the same crash bug as 1241217 moving up the stack now that bug 1241651 is fixed. tn: any thoughts on that one?
Flags: needinfo?(bugs) → needinfo?(tnikkel)

Comment 16

2 years ago
(In reply to Jet Villegas (:jet) from comment #14)
> Sure, I can help. Is the original signature still relevant?
> nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)
> 
> Or, are we only interested in hunting down ::GetRootPresContext()?

The GetRootPresContext stack. It's currently showing up as #35 in our experiment crash list - 

https://crash-stats.mozilla.org/search/?ActiveExperiment=e10s-beta46-noapz%40experiments.mozilla.org&ActiveExperimentBranch=experiment-no-addons&_facets=signature&_columns=signature&_columns=product&_columns=build_id&_columns=platform#facet-signature
Flags: needinfo?(jmathies)
(In reply to Jet Villegas (:jet) from comment #15)
> I wonder if this is the same crash bug as 1241217 moving up the stack now
> that bug 1241651 is fixed. tn: any thoughts on that one?

Oh dang, looks like you're right. We didn't fix anything there. Which means I have even less clue of what's going on in this bug :(

This looks like a tough one. The only road I see is code reading, random guesses (and I don't have many of those even), landing things that will provide clues in crash reports, waiting for crash reports, re-evaluating, and repeat. And with no current crashes on nightly, and only one crash on aurora that looks like a very long drawn out process.

Maybe someone else has a better idea?
Should have filed a new bug for this rather than hijack one from four years ago--there doesn't seem to be anything plugin related in these new stacks.
Group: core-security → dom-core-security
Keywords: csectype-uaf, sec-critical
Patch in bug 1260531 might help with this.
Seems to me we should indeed file a new bug for the e10s crashes we're seeing and focus on that one (also security sensitive, but may or may not have anything to do with plugin frames as this bug does).

Jet, can you please file a new bug, move the e10s flags over to the new one, and make sure that bug gets the attention it deserves (blocks e10s shipping, so needs someone on it).

Comment 21

2 years ago
OK, filed bug 1261175 for crashes related to ::GetRootPresContext()
(In reply to Jet Villegas (:jet) from comment #21)
> OK, filed bug 1261175 for crashes related to ::GetRootPresContext()

Could you please also CC e10s folks to that bug who were CCed to this bug and now does not have access to the new one?
tracking-e10s: m9+ → -
ni transferred to bug 1261175.
Flags: needinfo?(tnikkel)
Hi Jet, it's not clear if we've covered everything in the new bug 1261175, or if there is still an issue remaining here. CritSmash group is trying to determine if this bug should stay open as a sec-critical bug - with some additional action required - or if it it should be closed out in order to continue discussion in the new bug.

Do you have any thoughts?
Flags: needinfo?(bugs)

Comment 25

2 years ago
I'd close this one out unless you're seeing new crashes with the original signature
nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)
Flags: needinfo?(bugs)
I don't see any crashes with that signature.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
I think the signature just changed from nsObjectFrame to nsPluginFrame.
bp-d03ffdb7-9c76-4f64-8258-3878b2160426
Status: RESOLVED → REOPENED
Crash Signature: [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] [@ nsPresContext::GetRootPresContext()] [@ nsObjectFrame::SetInstanceOwner] [@ nsPresContext::GetRootPresContext] → [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] [@ nsPresContext::GetRootPresContext()] [@ nsObjectFrame::SetInstanceOwner] [@ nsPresContext::GetRootPresContext] [@ nsPluginFrame::SetInstanceOwner ]
Resolution: WORKSFORME → ---
Jet, looks like this signature changed and is still showing up in 46.0.1 and 47 beta. It may still affect 48 and 49 even though we aren't seeing crash reports. 

This and bug 1261175 (also sec-critical) still need owners.
status-firefox46: --- → affected
status-firefox47: --- → affected
Flags: needinfo?(bugs)

Updated

2 years ago
Flags: needinfo?(bugs)

Comment 29

2 years ago
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #28)
> Jet, looks like this signature changed and is still showing up in 46.0.1 and
> 47 beta. It may still affect 48 and 49 even though we aren't seeing crash
> reports. 
> 
> This and bug 1261175 (also sec-critical) still need owners.

Matt Woodrow is looking through the raw memory dumps for more clues here (and bug 1261175.)
Flags: needinfo?(matt.woodrow)
(In reply to Mats Palmgren (:mats) from comment #27)
> I think the signature just changed from nsObjectFrame to nsPluginFrame.
> bp-d03ffdb7-9c76-4f64-8258-3878b2160426

This crash is weird.

We manage to call mWidget->Show(false) and mWidget->Enable(false), but then we mWidget is the poison value when we try call mWidget->SetParent(nullptr);

The only possibility I can think of is that |this| has already been destroyed, and jemalloc hadn't written the poison value until this point.

That would suggest that nsPluginInstanceOwner::mPluginFrame is dangling, but I can't see how this would happen.
Flags: needinfo?(matt.woodrow)
Keywords: sec-critical → sec-high

Updated

2 years ago
status-firefox46: affected → wontfix
status-firefox47: affected → wontfix
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #28)
> Jet, looks like this signature changed and is still showing up in 46.0.1 and
> 47 beta. It may still affect 48 and 49 even though we aren't seeing crash
> reports. 

Now I see crashes on 48 but not 49 or 50, so it must be tied to the user population somehow.
This is still affecting 49, 50, and 45esr:  https://crash-stats.mozilla.com/signature/?signature=nsPresContext%3A%3AGetRootPresContext#bugzilla

Matt, is this still relevant or should those crashes be part of some new bug?
status-firefox49: --- → wontfix
status-firefox50: --- → affected
status-firefox-esr45: --- → affected
Flags: needinfo?(matt.woodrow)
I think this is still relevant, we just don't have any leads right now.
Flags: needinfo?(matt.woodrow)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #32)
> This is still affecting 49, 50, and 45esr: 
> https://crash-stats.mozilla.com/signature/
> ?signature=nsPresContext%3A%3AGetRootPresContext#bugzilla
> 
> Matt, is this still relevant or should those crashes be part of some new bug?

Actually, those crash reports are bug 1261175, not this one.
Crash Signature: [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] [@ nsPresContext::GetRootPresContext()] [@ nsObjectFrame::SetInstanceOwner] [@ nsPresContext::GetRootPresContext] [@ nsPluginFrame::SetInstanceOwner ] → [@ nsObjectFrame::SetInstanceOwner(nsPluginInstanceOwner*)] [@ nsObjectFrame::SetInstanceOwner] [@ nsPluginFrame::SetInstanceOwner ]
Summary: Crash nsObjectFrame::SetInstanceOwner → Crash nsPluginFrame::SetInstanceOwner
Crash volume for signature 'nsPresContext::GetRootPresContext':
 - nightly (version 52): 0 crashes from 2016-09-19.
 - aurora  (version 51): 12 crashes from 2016-09-19.
 - beta    (version 50): 417 crashes from 2016-09-20.
 - release (version 49): 9 crashes from 2016-09-05.
 - esr     (version 45): 109 crashes from 2016-07-25.

Crash volume on the last weeks (Week N is from 10-17 to 10-23):
            W. N-1  W. N-2  W. N-3  W. N-4
 - nightly       0       0       0       0
 - aurora        2       0       1       1
 - beta        123     113     107      19
 - release       2       3       3       0
 - esr          13      12      17      11

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora            #91
 - beta    #827      #16
 - release #10010
 - esr     #590
status-firefox51: --- → affected
we are a week away from RC, no fix in sight, this is now a wontfix for 50.
status-firefox50: affected → wontfix
status-firefox52: --- → affected
For "nsPresContext::GetRootPresContext" on Beta, we have:
(100.0% in signature vs 28.64% overall) Module "winspool.drv" = true
(86.02% in signature vs 43.62% overall) dom_ipc_enabled = 1

So it looks like we're crashing when printing (or after) printing something (because "winspool.drv" is loaded) and we're more often crashing with e10s enabled.
Marco, thank you for taking a look at this. Can you take this bug?
If you can not, can you help us find someone to make sure this doesn'st stay in limbo?
Flags: needinfo?(mcastelluccio)
Unfortunately I'm not sure who can take the bug.
Flags: needinfo?(mcastelluccio)
status-firefox51: affected → wontfix
status-firefox52: affected → fix-optional
status-firefox53: --- → affected
status-firefox54: --- → affected
Benjamin, you are the triage owner. Please find someone to work on this sec-high bug.
Assignee: nobody → benjamin
(In reply to Frederik Braun [:freddyb] from comment #40)
> Benjamin, you are the triage owner. Please find someone to work on this
> sec-high bug.
Flags: needinfo?(benjamin)

Comment 42

10 months ago
There are a total of 28 crashes in the past two weeks, and no steps to reproduce. Comment 37 is irrelevant because it's about the nsPresContext signature which is not part of this bug. And the signatures for this bug do not appear at all in e10s.

https://crash-stats.mozilla.com/search/?signature=%3DnsPluginFrame%3A%3ASetInstanceOwner&signature=%3DnsObjectFrame%3A%3ASetInstanceOwner&date=%3E%3D2017-01-18T16%3A42%3A02.000Z&date=%3C2017-02-01T16%3A42%3A02.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=address&_columns=reason&_columns=e10s_cohort&_columns=process_type#crash-reports

So no, I don't think there's any engineering action that can be taken on this bug.
Assignee: benjamin → nobody
Flags: needinfo?(benjamin)
Priority: -- → P3
Thanks for taking a look. Let's just close this incomplete, then.
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago10 months ago
Resolution: --- → INCOMPLETE
See Also: → bug 1335792

Updated

10 months ago
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.