Closed
Bug 1473637
Opened 6 years ago
Closed 6 years ago
heap-use-after-free in [@ mozilla::dom::ImageTracker::SetLockingState]
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla63
People
(Reporter: tsmith, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(4 keywords, Whiteboard: [post-critsmash-triage])
Crash Data
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
smaug
:
review+
|
Details | Diff | Splinter Review |
Found with m-c: BuildID=20180625170548 SourceStamp=5568d7d159358ce0e6c3357d5eb8f7b6eebc19f9 I am trying to get a working testcase at the moment I will attach it asap. ==11019==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000029a40 at pc 0x7fe512ec5bdf bp 0x7fff8178e5d0 sp 0x7fff8178e5c8 READ of size 8 at 0x60c000029a40 thread T0 (file:// Content) #0 0x7fe512ec5bde in Key src/xpcom/ds/nsPointerHashKeys.h #1 0x7fe512ec5bde in mozilla::dom::ImageTracker::SetLockingState(bool) src/dom/base/ImageTracker.cpp:118 #2 0x7fe512ec57bf in mozilla::dom::ImageTracker::~ImageTracker() src/dom/base/ImageTracker.cpp:27:3 #3 0x7fe51302b305 in Release src/obj-firefox/dist/include/mozilla/dom/ImageTracker.h:40:3 #4 0x7fe51302b305 in Release src/obj-firefox/dist/include/mozilla/RefPtr.h:42 #5 0x7fe51302b305 in Release src/obj-firefox/dist/include/mozilla/RefPtr.h:407 #6 0x7fe51302b305 in ~RefPtr src/obj-firefox/dist/include/mozilla/RefPtr.h:80 #7 0x7fe51302b305 in nsIDocument::~nsIDocument() src/dom/base/nsDocument.cpp:1561 #8 0x7fe51302d8e9 in nsDocument::~nsDocument() src/dom/base/nsDocument.cpp:1725:1 #9 0x7fe5160c0de8 in ~nsHTMLDocument src/dom/html/nsHTMLDocument.cpp:191:1 #10 0x7fe5160c0de8 in nsHTMLDocument::~nsHTMLDocument() src/dom/html/nsHTMLDocument.cpp:190 #11 0x7fe50fd746c1 in SnowWhiteKiller::~SnowWhiteKiller() src/xpcom/base/nsCycleCollector.cpp:2736:25 #12 0x7fe50fd7318a in nsCycleCollector::FreeSnowWhite(bool) src/xpcom/base/nsCycleCollector.cpp:2924:3 #13 0x7fe50fd7c43c in nsCycleCollector::BeginCollection(ccType, nsICycleCollectorListener*) src/xpcom/base/nsCycleCollector.cpp:3934:3 #14 0x7fe50fd7ba70 in nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*, bool) src/xpcom/base/nsCycleCollector.cpp:3755:9 #15 0x7fe50fd7f414 in nsCycleCollector_collect(nsICycleCollectorListener*) src/xpcom/base/nsCycleCollector.cpp:4328:21 #16 0x7fe513160a22 in nsJSContext::CycleCollectNow(nsICycleCollectorListener*) src/dom/base/nsJSEnvironment.cpp:1490:3 #17 0x7fe512cd0d8b in nsDOMWindowUtils::CycleCollect(nsICycleCollectorListener*) src/dom/base/nsDOMWindowUtils.cpp:1253:3 #18 0x7fe50ff22c61 in NS_InvokeByIndex src/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:106 #19 0x7fe5117ee400 in Invoke src/js/xpconnect/src/XPCWrappedNative.cpp:1703:12 #20 0x7fe5117ee400 in Call src/js/xpconnect/src/XPCWrappedNative.cpp:1219 #21 0x7fe5117ee400 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) src/js/xpconnect/src/XPCWrappedNative.cpp:1186 #22 0x7fe5117f3fb4 in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) src/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:893:12 #23 0x7fe51be64753 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/JSContext-inl.h:274:15 #24 0x7fe51be50460 in CallFromStack src/js/src/vm/Interpreter.cpp:526:12 #25 0x7fe51be50460 in Interpret(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:3122 #26 0x7fe51be32bdc in js::RunScript(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:421:12 #27 0x7fe51be64f42 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/Interpreter.cpp:493:15 #28 0x7fe51be65d42 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) src/js/src/vm/Interpreter.cpp:539:10 #29 0x7fe51c9be7aa in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) src/js/src/jsapi.cpp:2887:12 #30 0x7fe511725ad3 in xpc::FunctionForwarder(JSContext*, unsigned int, JS::Value*) src/js/xpconnect/src/ExportHelpers.cpp:319:18 #31 0x7fe51be64753 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/JSContext-inl.h:274:15 #32 0x7fe51be50460 in CallFromStack src/js/src/vm/Interpreter.cpp:526:12 #33 0x7fe51be50460 in Interpret(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:3122 #34 0x7fe51be32bdc in js::RunScript(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:421:12 #35 0x7fe51be64f42 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/Interpreter.cpp:493:15 #36 0x7fe51be65d42 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) src/js/src/vm/Interpreter.cpp:539:10 #37 0x7fe51c9be7aa in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) src/js/src/jsapi.cpp:2887:12 #38 0x7fe514d1e62c in mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) src/obj-firefox/dom/bindings/EventHandlerBinding.cpp:264:37 #39 0x7fe515d261dc in void mozilla::dom::EventHandlerNonNull::Call<nsISupports*>(nsISupports* const&, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JS::Realm*) src/obj-firefox/dist/include/mozilla/dom/EventHandlerBinding.h:363:12 #40 0x7fe515d23b69 in mozilla::JSEventHandler::HandleEvent(mozilla::dom::Event*) src/dom/events/JSEventHandler.cpp:214:12 #41 0x7fe515cea4ce in mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, mozilla::dom::Event*, mozilla::dom::EventTarget*) src/dom/events/EventListenerManager.cpp:1124:52 #42 0x7fe515cebc1a in mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event**, mozilla::dom::EventTarget*, nsEventStatus*) src/dom/events/EventListenerManager.cpp:1298:20 #43 0x7fe515cd4e7c in mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) src/dom/events/EventDispatcher.cpp:622:16 #44 0x7fe515cda2e0 in mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) src/dom/events/EventDispatcher.cpp:1088:9 #45 0x7fe515cdc9db in mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, mozilla::dom::Event*, nsPresContext*, nsEventStatus*) src/dom/events/EventDispatcher.cpp #46 0x7fe51312c5cb in nsINode::DispatchEvent(mozilla::dom::Event&, mozilla::dom::CallerType, mozilla::ErrorResult&) src/dom/base/nsINode.cpp:1088:5 #47 0x7fe512c7fd27 in nsContentUtils::DispatchEvent(nsIDocument*, nsISupports*, nsTSubstring<char16_t> const&, bool, bool, bool, bool*, bool) src/dom/base/nsContentUtils.cpp:4489:28 #48 0x7fe512c7fb04 in nsContentUtils::DispatchTrustedEvent(nsIDocument*, nsISupports*, nsTSubstring<char16_t> const&, bool, bool, bool*) src/dom/base/nsContentUtils.cpp:4457:10 #49 0x7fe51609810c in applyImpl<mozilla::dom::HTMLTrackElement, void (mozilla::dom::HTMLTrackElement::*)(const nsTSubstring<char16_t> &), StoreCopyPassByConstLRef<const nsTString<char16_t> > , 0> src/obj-firefox/dist/include/nsThreadUtils.h:1165:12 #50 0x7fe51609810c in apply<mozilla::dom::HTMLTrackElement, void (mozilla::dom::HTMLTrackElement::*)(const nsTSubstring<char16_t> &)> src/obj-firefox/dist/include/nsThreadUtils.h:1171 #51 0x7fe51609810c in mozilla::detail::RunnableMethodImpl<mozilla::dom::HTMLTrackElement*, void (mozilla::dom::HTMLTrackElement::*)(nsTSubstring<char16_t> const&), true, (mozilla::RunnableKind)0, nsTString<char16_t> const>::Run() src/obj-firefox/dist/include/nsThreadUtils.h:1216 #52 0x7fe50fec8a4e in mozilla::SchedulerGroup::Runnable::Run() src/xpcom/threads/SchedulerGroup.cpp:337:32 #53 0x7fe50fef4fdd in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1051:14 #54 0x7fe50fef37b0 in NS_ProcessNextEvent src/xpcom/threads/nsThreadUtils.cpp:519:10 #55 0x7fe50fef37b0 in SpinEventLoopUntil<mozilla::ProcessFailureBehavior::ReportToCaller, (lambda at src/xpcom/threads/nsThread.cpp:799:22)> src/obj-firefox/dist/include/nsThreadUtils.h:324 #56 0x7fe50fef37b0 in nsThread::Shutdown() src/xpcom/threads/nsThread.cpp:799 #57 0x7fe50ff00edf in nsThreadPool::Shutdown() src/xpcom/threads/nsThreadPool.cpp:347:17 #58 0x7fe50fed6c64 in applyImpl<nsIThreadPool, nsresult (nsIThreadPool::*)()> src/obj-firefox/dist/include/nsThreadUtils.h:1165:12 #59 0x7fe50fed6c64 in apply<nsIThreadPool, nsresult (nsIThreadPool::*)()> src/obj-firefox/dist/include/nsThreadUtils.h:1171 #60 0x7fe50fed6c64 in mozilla::detail::RunnableMethodImpl<nsCOMPtr<nsIThreadPool>, nsresult (nsIThreadPool::*)(), true, (mozilla::RunnableKind)0>::Run() src/obj-firefox/dist/include/nsThreadUtils.h:1216 #61 0x7fe50fef4fdd in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1051:14 #62 0x7fe50fef37b0 in NS_ProcessNextEvent src/xpcom/threads/nsThreadUtils.cpp:519:10 #63 0x7fe50fef37b0 in SpinEventLoopUntil<mozilla::ProcessFailureBehavior::ReportToCaller, (lambda at src/xpcom/threads/nsThread.cpp:799:22)> src/obj-firefox/dist/include/nsThreadUtils.h:324 #64 0x7fe50fef37b0 in nsThread::Shutdown() src/xpcom/threads/nsThread.cpp:799 #65 0x7fe50ff00edf in nsThreadPool::Shutdown() src/xpcom/threads/nsThreadPool.cpp:347:17 #66 0x7fe50fed6c64 in applyImpl<nsIThreadPool, nsresult (nsIThreadPool::*)()> src/obj-firefox/dist/include/nsThreadUtils.h:1165:12 #67 0x7fe50fed6c64 in apply<nsIThreadPool, nsresult (nsIThreadPool::*)()> src/obj-firefox/dist/include/nsThreadUtils.h:1171 #68 0x7fe50fed6c64 in mozilla::detail::RunnableMethodImpl<nsCOMPtr<nsIThreadPool>, nsresult (nsIThreadPool::*)(), true, (mozilla::RunnableKind)0>::Run() src/obj-firefox/dist/include/nsThreadUtils.h:1216 #69 0x7fe50fef4fdd in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1051:14 #70 0x7fe50fefbb89 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:519:10 #71 0x7fe510df975b in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:97:21 #72 0x7fe510d4e9ac in RunInternal src/ipc/chromium/src/base/message_loop.cc:325:10 #73 0x7fe510d4e9ac in RunHandler src/ipc/chromium/src/base/message_loop.cc:318 #74 0x7fe510d4e9ac in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:298 #75 0x7fe517935e29 in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:158:27 #76 0x7fe51bb9624f in XRE_RunAppShell() src/toolkit/xre/nsEmbedFunctions.cpp:896:22 #77 0x7fe510d4e9ac in RunInternal src/ipc/chromium/src/base/message_loop.cc:325:10 #78 0x7fe510d4e9ac in RunHandler src/ipc/chromium/src/base/message_loop.cc:318 #79 0x7fe510d4e9ac in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:298 #80 0x7fe51bb95c80 in XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:722:34 #81 0x4f1ce4 in content_process_main src/browser/app/../../ipc/contentproc/plugin-container.cpp:50:30 #82 0x4f1ce4 in main src/browser/app/nsBrowserApp.cpp:287 #83 0x7fe52d7e6f44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287 #84 0x421128 in _start (firefox+0x421128) 0x60c000029a40 is located 0 bytes inside of 128-byte region [0x60c000029a40,0x60c000029ac0) freed by thread T0 (file:// Content) here: #0 0x4c1532 in __interceptor_free /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:68:3 #1 0x7fe512b18b56 in imgRequestProxy::Release() src/image/imgRequestProxy.cpp:99:1 #2 0x7fe512db433f in Release src/obj-firefox/dist/include/mozilla/RefPtr.h:42:11 #3 0x7fe512db433f in Release src/obj-firefox/dist/include/mozilla/RefPtr.h:407 #4 0x7fe512db433f in assign_assuming_AddRef src/obj-firefox/dist/include/mozilla/RefPtr.h:67 #5 0x7fe512db433f in operator= src/obj-firefox/dist/include/mozilla/RefPtr.h:169 #6 0x7fe512db433f in nsImageLoadingContent::ClearCurrentRequest(nsresult, mozilla::Maybe<mozilla::OnNonvisible> const&) src/dom/base/nsImageLoadingContent.cpp:1461 #7 0x7fe512db4045 in nsImageLoadingContent::DestroyImageLoadingContent() src/dom/base/nsImageLoadingContent.cpp:115:3 #8 0x7fe515f261a6 in mozilla::dom::HTMLImageElement::~HTMLImageElement() src/dom/html/HTMLImageElement.cpp:132:3 #9 0x7fe515f2643d in mozilla::dom::HTMLImageElement::~HTMLImageElement() src/dom/html/HTMLImageElement.cpp:131:1 #10 0x7fe50fd746c1 in SnowWhiteKiller::~SnowWhiteKiller() src/xpcom/base/nsCycleCollector.cpp:2736:25 #11 0x7fe50fd7318a in nsCycleCollector::FreeSnowWhite(bool) src/xpcom/base/nsCycleCollector.cpp:2924:3 #12 0x7fe50fd7c43c in nsCycleCollector::BeginCollection(ccType, nsICycleCollectorListener*) src/xpcom/base/nsCycleCollector.cpp:3934:3 #13 0x7fe50fd7ba70 in nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*, bool) src/xpcom/base/nsCycleCollector.cpp:3755:9 #14 0x7fe50fd7f414 in nsCycleCollector_collect(nsICycleCollectorListener*) src/xpcom/base/nsCycleCollector.cpp:4328:21 #15 0x7fe513160a22 in nsJSContext::CycleCollectNow(nsICycleCollectorListener*) src/dom/base/nsJSEnvironment.cpp:1490:3 #16 0x7fe512cd0d8b in nsDOMWindowUtils::CycleCollect(nsICycleCollectorListener*) src/dom/base/nsDOMWindowUtils.cpp:1253:3 #17 0x7fe50ff22c61 in NS_InvokeByIndex src/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:106 #18 0x7fe5117ee400 in Invoke src/js/xpconnect/src/XPCWrappedNative.cpp:1703:12 #19 0x7fe5117ee400 in Call src/js/xpconnect/src/XPCWrappedNative.cpp:1219 #20 0x7fe5117ee400 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) src/js/xpconnect/src/XPCWrappedNative.cpp:1186 #21 0x7fe5117f3fb4 in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) src/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:893:12 #22 0x7fe51be64753 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/JSContext-inl.h:274:15 #23 0x7fe51be50460 in CallFromStack src/js/src/vm/Interpreter.cpp:526:12 #24 0x7fe51be50460 in Interpret(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:3122 #25 0x7fe51be32bdc in js::RunScript(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:421:12 #26 0x7fe51be64f42 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/Interpreter.cpp:493:15 #27 0x7fe51be65d42 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) src/js/src/vm/Interpreter.cpp:539:10 #28 0x7fe51c9be7aa in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) src/js/src/jsapi.cpp:2887:12 #29 0x7fe511725ad3 in xpc::FunctionForwarder(JSContext*, unsigned int, JS::Value*) src/js/xpconnect/src/ExportHelpers.cpp:319:18 #30 0x7fe51be64753 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/JSContext-inl.h:274:15 #31 0x7fe51be50460 in CallFromStack src/js/src/vm/Interpreter.cpp:526:12 #32 0x7fe51be50460 in Interpret(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:3122 #33 0x7fe51be32bdc in js::RunScript(JSContext*, js::RunState&) src/js/src/vm/Interpreter.cpp:421:12 #34 0x7fe51be64f42 in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) src/js/src/vm/Interpreter.cpp:493:15 #35 0x7fe51be65d42 in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) src/js/src/vm/Interpreter.cpp:539:10 #36 0x7fe51c9be7aa in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) src/js/src/jsapi.cpp:2887:12 #37 0x7fe514d1e62c in mozilla::dom::EventHandlerNonNull::Call(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) src/obj-firefox/dom/bindings/EventHandlerBinding.cpp:264:37 previously allocated by thread T0 (file:// Content) here: #0 0x4c1873 in malloc /builds/worker/workspace/moz-toolchain/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88:3 #1 0x4f2b6d in moz_xmalloc src/memory/mozalloc/mozalloc.cpp:70:17 #2 0x7fe512ad4702 in operator new src/obj-firefox/dist/include/mozilla/mozalloc.h:156:12 #3 0x7fe512ad4702 in imgLoader::CreateNewProxyForRequest(imgRequest*, nsILoadGroup*, nsIDocument*, imgINotificationObserver*, unsigned int, imgRequestProxy**) src/image/imgLoader.cpp:1168 #4 0x7fe512ae3746 in imgLoader::LoadImage(nsIURI*, nsIURI*, nsIURI*, mozilla::net::ReferrerPolicy, nsIPrincipal*, unsigned long, nsILoadGroup*, imgINotificationObserver*, nsINode*, nsIDocument*, unsigned int, nsISupports*, unsigned int, nsTSubstring<char16_t> const&, bool, imgRequestProxy**) src/image/imgLoader.cpp:2481:10 #5 0x7fe512c7a2a5 in nsContentUtils::LoadImage(nsIURI*, nsINode*, nsIDocument*, nsIPrincipal*, unsigned long, nsIURI*, mozilla::net::ReferrerPolicy, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, unsigned int, bool) src/dom/base/nsContentUtils.cpp:3718:21 #6 0x7fe512dbe0bb in nsImageLoadingContent::LoadImage(nsIURI*, bool, bool, nsImageLoadingContent::ImageLoadType, bool, nsIDocument*, unsigned int, nsIPrincipal*) src/dom/base/nsImageLoadingContent.cpp:985:17 #7 0x7fe515f2c2a6 in LoadImage src/dom/base/nsImageLoadingContent.h:148:12 #8 0x7fe515f2c2a6 in mozilla::dom::HTMLImageElement::LoadSelectedImage(bool, bool, bool) src/dom/html/HTMLImageElement.cpp:1016 #9 0x7fe515f8b3ed in mozilla::dom::ImageLoadTask::Run() src/dom/html/HTMLImageElement.cpp:99:17 #10 0x7fe50fd3c4a0 in mozilla::CycleCollectedJSContext::ProcessStableStateQueue() src/xpcom/base/CycleCollectedJSContext.cpp:331:12 #11 0x7fe50fd3e685 in mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int) src/xpcom/base/CycleCollectedJSContext.cpp:396:3 #12 0x7fe51177521d in XPCJSContext::AfterProcessTask(unsigned int) src/js/xpconnect/src/XPCJSContext.cpp:1218:30 #13 0x7fe50fef5836 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1086:24 #14 0x7fe50fefbb89 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:519:10 #15 0x7fe510df975b in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:97:21 #16 0x7fe510d4e9ac in RunInternal src/ipc/chromium/src/base/message_loop.cc:325:10 #17 0x7fe510d4e9ac in RunHandler src/ipc/chromium/src/base/message_loop.cc:318 #18 0x7fe510d4e9ac in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:298 #19 0x7fe517935e29 in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:158:27 #20 0x7fe51bb9624f in XRE_RunAppShell() src/toolkit/xre/nsEmbedFunctions.cpp:896:22 #21 0x7fe510d4e9ac in RunInternal src/ipc/chromium/src/base/message_loop.cc:325:10 #22 0x7fe510d4e9ac in RunHandler src/ipc/chromium/src/base/message_loop.cc:318 #23 0x7fe510d4e9ac in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:298 #24 0x7fe51bb95c80 in XRE_InitChildProcess(int, char**, XREChildData const*) src/toolkit/xre/nsEmbedFunctions.cpp:722:34 #25 0x4f1ce4 in content_process_main src/browser/app/../../ipc/contentproc/plugin-container.cpp:50:30 #26 0x4f1ce4 in main src/browser/app/nsBrowserApp.cpp:287 #27 0x7fe52d7e6f44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287 SUMMARY: AddressSanitizer: heap-use-after-free src/xpcom/ds/nsPointerHashKeys.h in Key Shadow bytes around the buggy address: 0x0c187fffd2f0: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa 0x0c187fffd300: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa 0x0c187fffd310: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c187fffd320: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x0c187fffd330: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x0c187fffd340: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd 0x0c187fffd350: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x0c187fffd360: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c187fffd370: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c187fffd380: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x0c187fffd390: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==11019==ABORTING
Reporter | ||
Updated•6 years ago
|
Summary: heap-use-after-free in [@ mozilla::dom::ImageTracker::~ImageTracker] → heap-use-after-free in [@ mozilla::dom::ImageTracker::SetLockingState]
Comment 1•6 years ago
|
||
Not blaming the stylo guys, but this class was created as part of a Stylo refactoring so it might not be a "dom" bug.
Keywords: sec-high
Comment 2•6 years ago
|
||
It looks like the object being UAFed is an imgRequestProxy. The weak reference appears to be the ImageTracker hash table. I would assume that we normal remove the proxy when we destroy it so I don't know what is going wrong.
Updated•6 years ago
|
Priority: -- → P1
Reporter | ||
Comment 3•6 years ago
|
||
Reporter | ||
Updated•6 years ago
|
Crash Signature: [@ mozilla::dom::ImageTracker::SetLockingState]
Flags: in-testsuite?
Keywords: testcase-wanted → testcase
Reporter | ||
Updated•6 years ago
|
status-firefox-esr52:
--- → affected
Comment 4•6 years ago
|
||
Thanks to Tyson's crash signature link, I looked at two crashes that had this signature and were crashing on poison values, and they both have crash stacks that look like the UAF from Tyson's test case! One is from 63 and the other is from 52, so I guess this is an old issue. bp-d13c450d-f0a4-4b87-8d94-d88d50180704
Assignee | ||
Updated•6 years ago
|
Flags: needinfo?(emilio)
Assignee | ||
Comment 5•6 years ago
|
||
I could repro this, so investigating for now.
Assignee: nobody → emilio
Assignee | ||
Comment 6•6 years ago
|
||
So, this is really interesting. This manages to tickle the CC in a way that we forget about unbinding connected stuff. In particular, we unlink HTMLBodyElement _while_ it's connected to the document (which gets unlinked later). That makes us unlink the shadow root pointer, without unbinding it first, which means we end up in a broken state where the Shadow Root thinks it's in the document, and has a host, but the host is no longer referencing the shadow root. This means that by the time the <body> is actually unbound, we forget to unbind the ShadowRoot, and the <img> in there, which means we loose track of the image request that was being tracked. I think the way to fix this is either unbinding the ShadowRoot from Unlink, and making it forget the host. WDYT Olli?
Blocks: shadowdom-initial-release
Flags: needinfo?(emilio) → needinfo?(bugs)
Comment 7•6 years ago
|
||
yeah, I guess ShadowRoot should be explicitly unbound during unlink.
Flags: needinfo?(bugs)
Updated•6 years ago
|
status-firefox61:
--- → wontfix
status-firefox62:
--- → affected
status-firefox-esr60:
--- → affected
tracking-firefox62:
--- → ?
tracking-firefox63:
--- → ?
tracking-firefox-esr60:
--- → ?
Assignee | ||
Comment 9•6 years ago
|
||
Flags: needinfo?(emilio)
Attachment #8991166 -
Flags: review?(bugs)
Comment 10•6 years ago
|
||
Comment on attachment 8991166 [details] [diff] [review] 0001-Unbind-shadow.patch >+ >+ shadowRoot->SetIsComposedDocParticipant(false); >+ // TODO: Should we clear the ShadowRoot::mHost member? It'd get cleared on >+ // the ShadowRoot unlinking anyway. We should not clear mHost here. That would be against normal CC handling, where in general object which has the strong pointer to some other object clears the edge during unlink. So, drop the comment? this is a bit hackish, but I don't have better ideas now. thanks!
Attachment #8991166 -
Flags: review?(bugs) → review+
Comment 11•6 years ago
|
||
It is still unclear to me why we crash in ImageTracker.cpp. That smells like a bug there too.
Comment 12•6 years ago
|
||
ah, https://searchfox.org/mozilla-central/source/dom/base/nsImageLoadingContent.cpp#1635, ok, nm,
Comment 13•6 years ago
|
||
Do we have any theories for why older branches appear to be hitting these crashes? I can't find any mention of shadowdom-related pref setting in any of the crash reports (in the userPrefs section).
Assignee | ||
Comment 14•6 years ago
|
||
I pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/5342b206e024 Few minutes before comment 13 since this only affects Nightly (we haven't shipped Shadow DOM anywhere else)... (In reply to Ryan VanderMeulen [:RyanVM] from comment #13) > Do we have any theories for why older branches appear to be hitting these > crashes? I can't find any mention of shadowdom-related pref setting in any > of the crash reports (in the userPrefs section). Hmm, not really. This particular crash is definitely shadow-DOM related. Looking at some of the stacks some of those seem related, some don't, but not sure there's anything actionable we can do without any STR for those... Olli, who owns the image tracker? Stopping storing raw pointers there or removing this wallpaper loop: https://searchfox.org/mozilla-central/rev/a80651653faa78fa4dfbd238d099c2aad1cec304/image/imgRequestProxy.cpp#155-157 And changing it by a MOZ_RELEASE_ASSERT(!mLockCount) should prevent any kind of security issues coming from this code. I'll file an imagelib bug with the later patch, I think we should do that.
Assignee | ||
Updated•6 years ago
|
Comment 15•6 years ago
|
||
tn seems to own imglib these days.
![]() |
||
Comment 16•6 years ago
|
||
Backed out for frequent wpt failures inputevent-constructor.htm/window-named-properties-002.html on Linux debug: https://hg.mozilla.org/integration/mozilla-inbound/rev/4f5a3c8b55f75d05b9ff30c7d31c17f52cbddf1b Push with test failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=7fb2269ca77ac9a71558a915d5beb047e356b633&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=usercancel&filter-resultStatus=runnable&filter-resultStatus=retry&filter-resultStatus=testfailed Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=187619020&repo=mozilla-inbound [task 2018-07-11T15:54:14.438Z] 15:54:14 INFO - PID 8393 | [Child 8453, Main Thread] WARNING: Using SubtreeRoot() on unlinked element?: file /builds/worker/workspace/build/src/dom/base/nsINode.cpp, line 295 [task 2018-07-11T15:54:14.439Z] 15:54:14 INFO - PID 8393 | [Child 8453, Main Thread] ###!!! ASSERTION: Removing id entry that doesn't exist: '!aElement->OwnerDoc()->IsHTMLDocument() || mIdContentList.Contains(aElement)', file /builds/worker/workspace/build/src/dom/base/nsDocument.cpp, line 560
Flags: needinfo?(emilio)
Assignee | ||
Comment 17•6 years ago
|
||
Relanded: https://hg.mozilla.org/integration/mozilla-inbound/rev/a5e9e9a0ff04
Flags: needinfo?(emilio)
![]() |
||
Comment 18•6 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a5e9e9a0ff04
Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Comment 19•6 years ago
|
||
This didn't have sec-approval for landing. I see claims that this "only affects nightly" but all the status flags say that isn't true. So, either it affects branches (and needed sec-approval before landing) or the flags are all wrong. We need a definitive answer on that.
Flags: needinfo?(emilio)
Comment 20•6 years ago
|
||
The patch landed in this bug affects nightly only. Shadow DOM isn't enabled elsewhere. There seems to be similar crashes affecting also branches, but that or those are different issue(s).
Updated•6 years ago
|
Updated•6 years ago
|
Flags: needinfo?(emilio)
Updated•6 years ago
|
tracking-firefox63:
? → ---
Comment 21•6 years ago
|
||
Our Firefox Trello board indicates that Shadow DOM is on track to be shipped with our 63 release, tracking+
tracking-firefox63:
--- → +
Updated•6 years ago
|
Flags: qe-verify+
Whiteboard: [post-critsmash-triage]
Comment 22•6 years ago
|
||
Hello, UBUNTU I have reproduced this bug on Ubuntu 16.04, using the test case attached and a "asan" build from 2018.07.05: https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.pushdate.2018.07.05.20180705214656.firefox.linux64-asan-opt/artifacts/public/build/target.tar.bz2 63.0a1 (2018-07-05) (64-bit) I have confirmed the fix on Ubuntu 16.04, using the test case attached and a "asan" build from today, 2018.08.02: https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.pushdate.2018.08.02.20180802130917.firefox.linux64-asan-opt/artifacts/public/build/target.tar.bz2 63.0a1 (2018-08-02) (64-bit) WINDOWS I have also reproduced the issue on Windows10, using the test case attached and a "asan" build from 2018.07.05: https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.pushdate.2018.07.05.20180705214656.firefox.win64-asan-opt/artifacts/public/build/install/sea/target.installer.exe 63.0a1 (2018-07-05) (64-bit) The reproduction wasn't 100% as expected; the tab crashed, but some other errors are being seen in the console: " JavaScript error: jar:file:///C:/Users/valentina.ona/Desktop/testxxx/omni.ja!/components/XULStore.js, line 65: Error: Can't find profile directory. JavaScript error: jar:file:///C:/Users/valentina.ona/Desktop/testxxx/omni.ja!/components/XULStore.js, line 65: Error: Can't find profile directory. [GPU 1788, Chrome_ChildThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [GPU 1788, Chrome_ChildThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [GPU 1788, Chrome_ChildThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [GPU 1788,[ Chr1ome5_ChildThread] WARNING: pipe2 er8ror: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 , Gecko_IOThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [Parent 12312, Gecko_IOThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [GPU 7556, Chrome_ChildThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [GPU 7556, Chro[me_CPhildTahread] WARNrING: pipe error: 1e09: file z:/builnd/btuil d/src/ipc/1chr2omium3/s1rc/c2hrome/comm,on /ipc_channGel_wien.ccc,k lineo 346_ IOThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [Parent 12312, Gecko_IOThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 [Parent 12312, Gecko_IOThread] WARNING: pipe error: 109: file z:/build/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 346 ###!!! [Parent][MessageChannel] Error: (msgtype=0x16008D,name=PBrowser::Msg_UpdateNativeWindowHandle) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x160080,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv [Parent 12312, Gecko_IOThread] WARNING: file z:/build/build/src/ipc/chromium/src/base/process_util_win.cc, line 188 " I have confirmed the fix on Windows 10, using the test case attached and a "asan" build from today, 2018.08.02: https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.pushdate.2018.08.02.20180802130917.firefox.win64-asan-opt/artifacts/public/build/install/sea/target.installer.exe 63.0a1 (2018-08-02) (64-bit) The original issue, the tab crash is not reproducing on Ubuntu, nor on Windows. I will set this issue as Verified Fixed in the latest Nightly, based on all the above. Thank you.
Status: RESOLVED → VERIFIED
Comment 23•6 years ago
|
||
While drafting this comment, I left the test case do its job (it keeps refreshing the page continuously). After posting the comment above, I have noticed that the browser entered in a "Not Responding" state. Emilio Cobos Álvarez, do you think this is an expected behavior? Thank you!
Flags: needinfo?(emilio)
Assignee | ||
Comment 24•6 years ago
|
||
You mean that the child process (that is, the content) is not responding? If so, to some extent, yes. The UI of the browser should still be responsive though, if it's not I'd file another bug.
Flags: needinfo?(emilio)
Comment 25•6 years ago
|
||
I have attempted to reproduce the behavior mentioned by me (above), but I wasn't able (anymore), using the latest available "asan" build. The "test case" attached was left to grind the browser for an about 30 minutes, but the browser did not reach a "not responding" state after all.
Comment 26•6 years ago
|
||
Marking the 63 status flag as "VERIFIED" and removing the QE-Verify bug flag. Thank you!
Flags: qe-verify+
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•4 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•