Closed Bug 899022 Opened 11 years ago Closed 11 years ago

crash in nsCOMPtr_base::assign_with_AddRef | nsWindowRoot::PreHandleEvent

Categories

(Core :: DOM: Events, defect)

All
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla26
Tracking Status
firefox22 --- wontfix
firefox23 --- wontfix
firefox24 + fixed
firefox25 + fixed
firefox26 + fixed
firefox-esr17 24+ fixed
b2g18 24+ fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- wontfix
b2g-v1.1hd --- fixed

People

(Reporter: scoobidiver, Assigned: smaug)

Details

(Keywords: crash, csectype-uaf, sec-critical, Whiteboard: [adv-main24+][adv-esr1709+])

Crash Data

Attachments

(2 files)

It's #10 browser crasher on Mac OS X in 22.0.

Signature 	nsCOMPtr_base::assign_with_AddRef(nsISupports*) | nsWindowRoot::PreHandleEvent(nsEventChainPreVisitor&) More Reports Search
UUID 	b7fb3d22-1570-4eb8-8c15-e7d7a2130729
Date Processed	2013-07-29 04:07:12.795335
Uptime	35480
Install Age 	94426 since version was first installed.
Install Time 	2013-07-28 01:53:08
Product 	Firefox
Version 	23.0
Build ID 	20130725195523
Release Channel 	beta
OS 	Mac OS X
OS Version 	10.8.4 12E55
Build Architecture 	amd64
Build Architecture Info 	family 6 model 23 stepping 10 | 2
Crash Reason 	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address 	0x8
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x 863GL Layers? GL Context? GL Context+ GL Layers+ 

Frame 	Module 	Signature 	Source
0 	XUL 	nsCOMPtr_base::assign_with_AddRef(nsISupports*) 	obj-firefox/x86_64/xpcom/build/nsCOMPtr.cpp
1 	XUL 	nsWindowRoot::PreHandleEvent(nsEventChainPreVisitor&) 	obj-firefox/x86_64/dist/include/nsCOMPtr.h
2 	XUL 	nsEventDispatcher::Dispatch(nsISupports*, nsPresContext*, nsEvent*, nsIDOMEvent*, nsEventStatus*, nsDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) 	content/events/src/nsEventDispatcher.cpp
3 	XUL 	nsEventDispatcher::DispatchDOMEvent(nsISupports*, nsEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) 	content/events/src/nsEventDispatcher.cpp
4 	XUL 	nsINode::DispatchEvent(nsIDOMEvent*, bool*) 	content/base/src/nsINode.cpp
5 	XUL 	nsContentUtils::DispatchEvent(nsIDocument*, nsISupports*, nsAString_internal const&, bool, bool, bool, bool*) 	content/base/src/nsContentUtils.cpp
6 	XUL 	nsContentUtils::DispatchTrustedEvent(nsIDocument*, nsISupports*, nsAString_internal const&, bool, bool, bool*) 	content/base/src/nsContentUtils.cpp
7 	XUL 	nsGlobalWindow::FireOfflineStatusEvent() 	dom/base/nsGlobalWindow.cpp
8 	XUL 	nsGlobalWindow::Observe(nsISupports*, char const*, unsigned short const*) 	dom/base/nsGlobalWindow.cpp
9 	XUL 	nsObserverList::NotifyObservers(nsISupports*, char const*, unsigned short const*) 	xpcom/ds/nsObserverList.cpp
10 	XUL 	nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 	xpcom/ds/nsObserverService.cpp
11 	XUL 	nsIOService::SetOffline(bool) 	netwerk/base/src/nsIOService.cpp
12 	XUL 	nsIOService::Observe(nsISupports*, char const*, unsigned short const*) 	netwerk/base/src/nsIOService.cpp
13 	XUL 	_ZThn8_N11nsIOService7ObserveEP11nsISupportsPKcPKt 	netwerk/base/src/nsIOService.cpp
14 	XUL 	nsObserverList::NotifyObservers(nsISupports*, char const*, unsigned short const*) 	xpcom/ds/nsObserverList.cpp
15 	XUL 	nsObserverService::NotifyObservers(nsISupports*, char const*, unsigned short const*) 	xpcom/ds/nsObserverService.cpp
16 	XUL 	nsXREDirProvider::DoShutdown() 	toolkit/xre/nsXREDirProvider.cpp
17 	XUL 	ScopedXPCOMStartup::~ScopedXPCOMStartup() 	toolkit/xre/nsAppRunner.cpp
18 	XUL 	XREMain::XRE_main(int, char**, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp
19 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp
20 	firefox 	main 	browser/app/nsBrowserApp.cpp
21 	firefox 	start 	

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsCOMPtr_base%3A%3Aassign_with_AddRef%28nsISupports*%29+|+nsWindowRoot%3A%3APreHandleEvent%28nsEventChainPreVisitor%26%29
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=%400x0+|+nsCOMPtr_base%3A%3Aassign_with_AddRef%28nsISupports*%29+|+nsWindowRoot%3A%3APreHandleEvent%28nsEventChainPreVisitor%26%29
Assignee: nobody → bugs
Group: core-security
Attached patch patchSplinter Review
Attachment #786050 - Flags: review?(continuation)
Comment on attachment 786050 [details] [diff] [review]
patch

Review of attachment 786050 [details] [diff] [review]:
-----------------------------------------------------------------

:(
Attachment #786050 - Flags: review?(continuation) → review+
Comment on attachment 786050 [details] [diff] [review]
patch

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
It is easy to see what the problem is but I don't know how to reproduce the crash

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Check-in comment will be about cycle collecting the window.

Which older supported branches are affected by this flaw?
All since bug 54203 (year 2000)

Do you have backports for the affected branches? Yes

How likely is this patch to cause regressions; how much testing does it need?
It makes one reference strong, so would be good to get some testing in order to make sure
there are no memory leaks.
(even if the strong reference is added to the cycle collection)
Attachment #786050 - Flags: sec-approval?
Attachment #786050 - Flags: approval-mozilla-release?
Attachment #786050 - Flags: approval-mozilla-esr17?
Attachment #786050 - Flags: approval-mozilla-beta?
Attachment #786050 - Flags: approval-mozilla-b2g18?
Attachment #786050 - Flags: approval-mozilla-aurora?
Comment on attachment 786050 [details] [diff] [review]
patch

Sec-approval+ for trunk.

Once this is in, please also check it into Aurora and Beta. Tiny patch!

I can't approve for b2g or ESR on my own without release management though.
Attachment #786050 - Flags: sec-approval?
Attachment #786050 - Flags: sec-approval+
Attachment #786050 - Flags: approval-mozilla-beta?
Attachment #786050 - Flags: approval-mozilla-beta+
Attachment #786050 - Flags: approval-mozilla-aurora?
Attachment #786050 - Flags: approval-mozilla-aurora+
Should we take this on ESR and B2G?
Probably.
https://hg.mozilla.org/mozilla-central/rev/6b67f2733685
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Comment on attachment 786050 [details] [diff] [review]
patch

This wouldn't drive a 23.0.2 so minusing for m-r branch, it will be in 24 and ESR 24.
Attachment #786050 - Flags: approval-mozilla-release?
Attachment #786050 - Flags: approval-mozilla-release-
Attachment #786050 - Flags: approval-mozilla-esr17?
Attachment #786050 - Flags: approval-mozilla-esr17+
Whiteboard: [adv-main24+][adv-esr1709+]
In the absence of a test case, comment 4 says:

"It makes one reference strong, so would be good to get some testing in order to make sure there are no memory leaks."

If there's anything you can suggest for QA to do - to verify that this is a good fix - please let us know. At the moment, it doesn't appear that there's anything we can do for verification.
With "some testing" I meant enough mochitest runs and me running about:cc and checking whether
there are leaks. Haven't seen anything.
b2g18 is frozen for non-leo+ blockers. Please request blocking status if you feel that this must land there.
Attachment #786050 - Flags: approval-mozilla-b2g18?
Comment on attachment 786050 [details] [diff] [review]
patch

[Triage Comment]
Attachment #786050 - Flags: approval-mozilla-b2g18+
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #15)
> b2g18 is frozen for non-leo+ blockers. Please request blocking status if you
> feel that this must land there.

I'm sorry, I fucked this up. I fed RyanVM bad information. The v1.1 branch will be open until 3/3/2014, as it's being maintained for security until that time.
Group: core-security
You need to log in before you can comment on or make changes to this bug.