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)
Tracking
()
People
(Reporter: scoobidiver, Assigned: smaug)
Details
(Keywords: crash, csectype-uaf, sec-critical, Whiteboard: [adv-main24+][adv-esr1709+])
Crash Data
Attachments
(2 files)
1.69 KB,
patch
|
mccr8
:
review+
abillings
:
approval-mozilla-aurora+
abillings
:
approval-mozilla-beta+
lsblakk
:
approval-mozilla-release-
lsblakk
:
approval-mozilla-esr17+
akeybl
:
approval-mozilla-b2g18+
abillings
:
sec-approval+
|
Details | Diff | Splinter Review |
1.91 KB,
patch
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•11 years ago
|
status-firefox24:
--- → affected
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → bugs
Assignee | ||
Updated•11 years ago
|
Group: core-security
Assignee | ||
Comment 1•11 years ago
|
||
Attachment #786050 -
Flags: review?(continuation)
Comment 2•11 years ago
|
||
Comment on attachment 786050 [details] [diff] [review] patch Review of attachment 786050 [details] [diff] [review]: ----------------------------------------------------------------- :(
Attachment #786050 -
Flags: review?(continuation) → review+
Updated•11 years ago
|
Keywords: csec-uaf,
sec-critical
Updated•11 years ago
|
status-b2g18:
--- → affected
status-firefox-esr17:
--- → affected
Assignee | ||
Comment 3•11 years ago
|
||
Assignee | ||
Comment 4•11 years ago
|
||
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 5•11 years ago
|
||
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+
Updated•11 years ago
|
status-firefox26:
--- → affected
tracking-firefox24:
--- → +
tracking-firefox25:
--- → +
tracking-firefox26:
--- → +
Assignee | ||
Comment 6•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/6b67f2733685
Comment 7•11 years ago
|
||
Should we take this on ESR and B2G?
tracking-b2g18:
--- → ?
tracking-firefox-esr17:
--- → ?
Assignee | ||
Comment 8•11 years ago
|
||
Probably.
Comment 9•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/6b67f2733685
Status: NEW → RESOLVED
Closed: 11 years ago
status-b2g18-v1.0.0:
--- → wontfix
status-b2g18-v1.0.1:
--- → wontfix
status-b2g-v1.1hd:
--- → affected
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Comment 10•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/69d2e4db243b https://hg.mozilla.org/releases/mozilla-beta/rev/80c22c20bde5
Updated•11 years ago
|
Comment 11•11 years ago
|
||
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+
Updated•11 years ago
|
Whiteboard: [adv-main24+][adv-esr1709+]
Comment 13•11 years ago
|
||
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.
Assignee | ||
Comment 14•11 years ago
|
||
With "some testing" I meant enough mochitest runs and me running about:cc and checking whether there are leaks. Haven't seen anything.
Comment 15•11 years ago
|
||
b2g18 is frozen for non-leo+ blockers. Please request blocking status if you feel that this must land there.
Updated•11 years ago
|
Attachment #786050 -
Flags: approval-mozilla-b2g18?
Updated•11 years ago
|
Comment 16•11 years ago
|
||
Comment on attachment 786050 [details] [diff] [review] patch [Triage Comment]
Attachment #786050 -
Flags: approval-mozilla-b2g18+
Comment 17•11 years ago
|
||
(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.
Updated•11 years ago
|
Updated•10 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•