Closed Bug 643062 Opened 13 years ago Closed 13 years ago
Crash in xul!ns
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:18.104.22.168) Gecko/20110303 Firefox/3.6.15 Build Identifier: Description: Following testcase uses a combination of frames, iframes and a xul element. The observed crashes show exploitable behaviour, such as: 32-bit Linux Firefox 3.6.15: $eax 0x5f5c4c1 99992769 (gdb) x/10i $eip => 0xf768436a: call *0x128(%eax) Affected Versions: Firefox 3.6.15 (Windows and Linux) Firefox 4 is not affected, as XUL is disabled by default. Testcase: The testcase is attached as an HTML file. It will crash the browser on opening after several reloads. Testcase Notes: The testcase uses Jesse's quitter extension (https://www.squarefree.com/extensions/quitter.xpi) to reliably trigger garbage collection. Stack Backtrace: Following testcases have been observed: Windows Firefox 3.6.15: (1718.1944): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. xul!nsXBLBinding::AllowScripts+0x54: 6165e644 8b8024010000 mov eax,dword ptr [eax+124h] ds:002b:010061e5=???????? xul!nsXBLBinding::AllowScripts(void)+0x54 xul!nsRunnable::Release(void)+0x10 xul!nsRunnableMethod<nsOggDecoder,void>::Run(void)+0xe xul!nsGenericElement::doReplaceOrInsertBefore(int aReplace = 90637520, class nsIDOMNode * aNewChild = 0x010060c1, class nsIDOMNode * aRefChild = 0x00000001, class nsIContent * aParent = 0x05e1fbc0, class nsIDocument * aDocument = 0x07756870, class nsIDOMNode ** aReturn = 0x07756870)+0x1b5 xul!xpc_qsUnwrapArgImpl(struct JSContext * cx = 0x05e80a80, int v = 298980787, struct nsID * iid = 0x0060c154, void ** ppArg = 0x006578a0, class nsISupports ** ppArgRef = 0x80002e93, int * vp = 0x32dd8a5f)+0x95 xul!nsGenericElement::AppendChild(class nsIDOMNode * aNewChild = 0x05565bd0, class nsIDOMNode ** aReturn = 0x05fe1793)+0x17 xul!nsIDOMNode_AppendChild(struct JSContext * cx = 0x05565bd0, unsigned int argc = 0x5fe1793, int * vp = 0x00200445)+0xf1 js3250!js_FillPropertyCache(struct JSContext * cx = 0x8b04508b, struct JSObject * obj = 0x3b0c244c, unsigned int scopeIndex = 0x8b0e7511, unsigned int protoIndex = 0x413b0840, struct JSObject * pobj = 0xb8067504, struct JSScopeProperty * sprop = 0x00000001, int adding = -1010814013)+0x499 js3250!js_Interpret(struct JSContext * cx = 0x00000000)+0x3270 Ubuntu 64-bit Firefox: (gdb) bt 30 #0 0x00007ffff6d2fd40 in GetDocument (this=0x7fffda3026c0) at ../../../dist/include/nsNodeInfoManager.h:117 #1 GetDocument (this=0x7fffda3026c0) at ../../../dist/include/nsINodeInfo.h:291 #2 GetOwnerDoc (this=0x7fffda3026c0) at ../../../dist/include/nsINode.h:367 #3 nsXBLBinding::AllowScripts (this=0x7fffda3026c0) at nsXBLBinding.cpp:1394 #4 0x00007ffff6d30c41 in nsXBLBinding::ExecuteAttachedHandler (this=0x7fffda3026c0) at nsXBLBinding.cpp:978 #5 0x00007ffff6d30c32 in nsXBLBinding::ExecuteAttachedHandler (this=0x7fffda302780) at nsXBLBinding.cpp:974 #6 0x00007ffff6d9895d in nsRunnableMethod<nsXBLBinding, void>::Run (this=<value optimized out>) at ../../dist/include/nsThreadUtils.h:282 #7 0x00007ffff6c1a34d in nsContentUtils::RemoveScriptBlocker () at nsContentUtils.cpp:4488 #8 0x00007ffff6c353d2 in nsDocument::EndUpdate (this=0x7fffd917c800, aUpdateType=<value optimized out>) at nsDocument.cpp:3859 #9 0x00007ffff6ce78f9 in nsHTMLDocument::EndUpdate (this=0x7fffe2335e70, aUpdateType=4294954700) at nsHTMLDocument.cpp:3034 #10 0x00007ffff6c4df5f in ~mozAutoDocConditionalContentUpdateBatch (aReplace=<value optimized out>, aNewChild=<value optimized out>, aRefChild=0x0, aParent=0x7fffda344330, aDocument=0x7fffd917c800, aReturn=<value optimized out>) at mozAutoDocUpdate.h:112 #11 nsGenericElement::doReplaceOrInsertBefore (aReplace=<value optimized out>, aNewChild=<value optimized out>, aRefChild=0x0, aParent=0x7fffda344330, aDocument=0x7fffd917c800, aReturn=<value optimized out>) at nsGenericElement.cpp:3956 #12 0x00007ffff69c3e65 in nsIDOMNode_AppendChild (cx=0x7fffe22be800, argc=<value optimized out>, vp=0x7fffda39e108) at dom_quickstubs.cpp:2617 #13 0x00007ffff61df39b in js_Interpret (cx=0x7fffe22be800) at jsops.cpp:2208 #14 0x00007ffff61e6efd in js_Execute (cx=0x7fffe22be800, chain=<value optimized out>, script=<value optimized out>, down=0x0, flags=4159402048, result=0x0) at jsinterp.cpp:1601 #15 0x00007ffff6191c19 in JS_EvaluateUCScriptForPrincipals (cx=0x7fffe22be800, obj=0x7fffe4a78e00, principals=<value optimized out>, chars=<value optimized out>, length=<value optimized out>, filename=<value optimized out>, lineno=28, rval=0x0) at jsapi.cpp:5056 #16 0x00007ffff6d64192 in nsJSContext::EvaluateString (this=0x7fffe22b5220, aScript=<value optimized out>, aScopeObject=0x7fffe4a78e00, aPrincipal=<value optimized out>, aURL=<value optimized out>, aLineNo=<value optimized out>, aVersion=0, aRetValue=0x0, aIsUndefined=0x7fffffffd908) at nsJSEnvironment.cpp:1764 #17 0x00007ffff6d7e2d5 in nsGlobalWindow::RunTimeout (this=0x7fffd9156800, aTimeout=0x7fffda3c4640) at nsGlobalWindow.cpp:8186 #18 0x00007ffff6d7e644 in nsGlobalWindow::TimerCallback (aTimer=<value optimized out>, aClosure=0x7fffffffcecc) at nsGlobalWindow.cpp:8539 #19 0x00007ffff727bdc5 in nsTimerImpl::Fire (this=0x7fffda3ab290) at nsTimerImpl.cpp:427 #20 0x00007ffff727be8f in nsTimerEvent::Run (this=<value optimized out>) at nsTimerImpl.cpp:519 #21 0x00007ffff72798ef in nsThread::ProcessNextEvent (this=0x7fffed12c9d0, mayWait=0, result=0x7fffffffda0c) at nsThread.cpp:527 #22 0x00007ffff724d2f5 in NS_ProcessNextEvent_P (thread=0x7fffe2335e70, mayWait=-12596) at nsThreadUtils.cpp:250 #23 0x00007ffff71d5730 in mozilla::ipc::MessagePump::Run (this=0x7fffed1ca780, aDelegate=0x7fffed1fa1c0) at MessagePump.cpp:110 #24 0x00007ffff7221c9c in MessageLoop::Run (this=0x7fffed1fa1c0) at ./src/base/message_loop.cc:173 #25 0x00007ffff713621d in nsBaseAppShell::Run (this=0x7fffe79ffd60) at nsBaseAppShell.cpp:174 #26 0x00007ffff7002e7e in nsAppStartup::Run (this=0x7fffe6392d40) at nsAppStartup.cpp:183 #27 0x00007ffff6962207 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>) at nsAppRunner.cpp:3483 #28 0x00007ffff7ff3fa1 in main (argc=1, argv=0x7fffffffe3f8) at nsBrowserApp.cpp:158 VulnDev reference : vd11004 reported by nils of vulndev ltd Reproducible: Always
Olli, can you look into this one? If this looks like it's not sg:critical, let us know and we'll adjust...
Assignee: nobody → Olli.Pettay
Interesting. I never got email about this.
So far I'm not reproducing the crash in 3.6.18pre (on Mac, if it matters). Is it possible we fixed this in 3.6.17 via a different bug? I notice comment 0 says windows and linux. Does that mean you know Mac is unaffected, or simply that you didn't test on Mac?
(In reply to comment #5) > So far I'm not reproducing the crash in 3.6.18pre (on Mac, if it matters). Is > it possible we fixed this in 3.6.17 via a different bug? > > I notice comment 0 says windows and linux. Does that mean you know Mac is > unaffected, or simply that you didn't test on Mac? I haven't tested mac in this case. Will do so later. I just tested 3.6.18pre on Windows, which still crashes while trying to execute an invalid memory address.
I just confirmed the crash on mac with firefox 3.6.18pre. The crash shows similar behaviour and tries to execute what seems to be data on the heap. Daniel, have you had the quitter extension enabled while testing on mac?
Attachment #520378 - Attachment description: testcase (crashes Firefox 3.6.15) → testcase (crashes Firefox 3.6.15, requires quitter)
You're right, I glossed over the Quitter requirement. Crash seems to happen on 4.0.x as well according to crash-stats. Don't have any idea if this is people who have enabled remote XUL or if somehow some of our own chrome code (or an addon?) is causing it. Of course it could be coincidental and not the same crash at all. https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=nsXBLBinding%3A%3AAllowScripts&reason_type=contains&date=05%2F13%2F2011%2010%3A24%3A01&range_value=3&range_unit=weeks&hang_type=any&process_type=any&do_query=1&signature=nsXBLBinding%3A%3AAllowScripts
Status: UNCONFIRMED → NEW
Ever confirmed: true
Nils, can you try to reproduce this in Firefox 5 and/or Firefox 6?
Even after enabling support for remote XUL, i can't reproduce in Firefox 5 beta.
Ok, thanks for testing!
Ah, this looks a bit like Bug 529087.
This fixes the crash, at least on 1.9.2, but I don't know why :)
I mean, why is ExecuteAttachedHandler on removed binding.
Comment on attachment 536704 [details] [diff] [review] patch Ok, if DOMClassInfo calls nsXBLBinding::ExecuteAttachedHandler using a scriptrunner, nothing guarantees that the binding is still bound to element when ExecuteAttachedHandler runs. Safer option would be to make mBoundElement nsWeakPtr, but that would be a bit slow.
Attachment #536704 - Flags: review?(jonas)
Attachment #536704 - Flags: review?(jonas) → review+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #13) > This fixes the crash, at least on 1.9.2, but I don't know why :) But it hasn't been checked in on 1.9.2 yet, right? Is this the patch you want approval on, or is that the one you checked into mozilla-central (or are they the same)?
blocking1.9.2: needed → .20+
Comment on attachment 536704 [details] [diff] [review] patch This has been baking on trunk quite some time.
Attachment #536704 - Flags: approval22.214.171.124?
Comment on attachment 536704 [details] [diff] [review] patch Approved for 126.96.36.199, a=dveditz
Attachment #536704 - Flags: approval188.8.131.52? → approval184.108.40.206+
Running the testcase (with quitter installed) on 220.127.116.11 on XP, I cannot get the crash to reproduce. Is there any special trick here beyond reloading the page repeatedly?
Whiteboard: [sg:critical?] → [sg:critical?][qa-examined-192][qa-needs-STR]
You need to log in before you can comment on or make changes to this bug.