Closed
Bug 315254
Opened 14 years ago
Closed 14 years ago
CVE-2006-1529 Crash [@ js_FreeStack] involving the unknown protocol error dialog
Categories
(Core :: Networking, defect, critical)
Core
Networking
Tracking
()
RESOLVED
FIXED
People
(Reporter: jruderman, Assigned: mrbkap)
References
Details
(4 keywords, Whiteboard: [sg:critical?] Doesn't appear to affect ff1.0 [rft-dl])
Crash Data
Attachments
(4 files)
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051105 Firefox/1.6a1 Found using http://toadstool.se/software/iexploder/ (Tests #8200-8250). See also bug 312680 and bug 74331.
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Reporter | ||
Comment 3•14 years ago
|
||
TB11505985Z
Assignee | ||
Comment 4•14 years ago
|
||
See also bug 315254.
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > See also bug 315254. It's late :-(... I meant to point to bug 310508.
Comment 6•14 years ago
|
||
With a debug build, I get this assertion when the dialog opens: ###!!! ASSERTION: JSContext still in threadjscontextstack!: '!tls->GetJSContextStack() || !tls->GetJSContextStack()-> DEBUG_StackHasJSContext(aJSContext)', file /build/andrew/moz-debug/mozilla/js/src/xpconnect/src/nsXPConnect.cpp, line 1199 The fun in valgrind starts after I click OK in the dialog: Invalid read of size 4 JS_GetContextThread (jsapi.c:4744) XPCCallContext::XPCCallContext(XPCContext::LangType, JSContext*, JSObject*, JSObject*, long, unsigned, long*, long*) (xpccallcontext.cpp:99) nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) (xpcwrappedjsclass.cpp:1002) nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*) (xpcwrappedjs.cpp:461) PrepareAndDispatch (xptcstubs_gcc_x86_unix.cpp:100) nsBrowserStatusFilter::ProcessTimeout() (nsBrowserStatusFilter.cpp:295) nsBrowserStatusFilter::TimeoutHandler(nsITimer*, void*) (nsBrowserStatusFilter.cpp:313) nsTimerImpl::Fire() (nsTimerImpl.cpp:400) handleTimerEvent(TimerEventType*) (nsTimerImpl.cpp:465) PL_HandleEvent (plevent.c:688) PL_ProcessPendingEvents (plevent.c:623) nsEventQueueImpl::ProcessPendingEvents() (nsEventQueue.cpp:417) Address 0x20CBC010 is not stack'd, malloc'd or (recently) free'd
Comment 7•14 years ago
|
||
I saw this crash while testing today's candidate build - TB11570612Z. Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5.
Reporter | ||
Comment 8•14 years ago
|
||
Marcia's crash involves a different networking-related dialog but probably has the same underlying problem. I'll attach a testcase for Marcia's crash in a minute.
Reporter | ||
Comment 9•14 years ago
|
||
Reporter | ||
Updated•14 years ago
|
Attachment #202177 -
Attachment mime type: text/plain → text/html
Updated•14 years ago
|
OS: MacOS X → All
Hardware: Macintosh → All
Comment 10•14 years ago
|
||
talkback: TB11693607G may be this
Updated•14 years ago
|
Assignee: darin → mrbkap
Comment 11•14 years ago
|
||
Probably exploitable given valgrind showing illegal memory writes
Group: security
Whiteboard: [sg:critical?]
Comment 12•14 years ago
|
||
Another talkback: TB12992699 My crash looks like: FreeArenaList [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsarena.c, line 335] nsWindowWatcher::OpenWindow [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 477] nsPromptService::DoDialog [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 634] nsPromptService::Alert [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 133] nsPrompt::Alert [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/embedding/components/windowwatcher/src/nsPrompt.cpp, line 217] nsDocShell::DisplayLoadError [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp, line 3045] nsDocShell::InternalLoad [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp, line 6585] nsDocShell::LoadURI [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/docshell/base/nsDocShell.cpp, line 793] nsFrameLoader::LoadFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsFrameLoader.cpp, line 172] nsGenericHTMLFrameElement::LoadSrc [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 3538] nsGenericElement::AppendChildTo [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2803] SinkContext::OpenContainer [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 1221] HTMLContentSink::OpenContainer [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 2933] CNavDTD::HandleDefaultStartToken [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 1283] CNavDTD::HandleStartToken [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 1668] CNavDTD::HandleToken [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 955] CNavDTD::BuildModel [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 458] CNavDTD::BuildNeglectedTarget [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 516]
Updated•14 years ago
|
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
Comment 13•14 years ago
|
||
Bkap - can you take a second look at this to figure out whether we can get it in 1.8.0.2?
Updated•14 years ago
|
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Assignee | ||
Comment 14•14 years ago
|
||
I think the patch I just attached to bug 310508 will fix this bug as well.
Assignee | ||
Comment 15•14 years ago
|
||
This should now be fixed on trunk since the patch for bug 310508 is checked in.
Assignee | ||
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•14 years ago
|
||
This is now fixed on the 1.8 branches (thanks to bug 310508).
Keywords: fixed1.8.0.2,
fixed1.8.1
Updated•14 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?] Doesn't appear to affect ff1.0
Comment 17•14 years ago
|
||
Marking [rft-dl] (ready for testing in Firefox 1.5.0.2 release candidates)
Whiteboard: [sg:critical?] Doesn't appear to affect ff1.0 → [sg:critical?] Doesn't appear to affect ff1.0 [rft-dl]
Comment 18•14 years ago
|
||
v.fixed on 1.8.0 branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060301 Firefox/1.5.0.1, no crash with either testcase.
Keywords: fixed1.8.0.2 → verified1.8.0.2
Updated•14 years ago
|
Flags: in-testsuite+
Updated•14 years ago
|
Summary: Crash [@ js_FreeStack] involving the unknown protocol error dialog → CVE-2006-1529 Crash [@ js_FreeStack] involving the unknown protocol error dialog
Updated•14 years ago
|
Group: security
Comment 19•14 years ago
|
||
https://bugzilla.mozilla.org/attachment.cgi?id=201980 ff2b2 debug/nightly windows/linux no crash https://bugzilla.mozilla.org/attachment.cgi?id=202177 ff2b2 debug/nightly windows/linux no crash verified fixed 1.8
Keywords: fixed1.8.1 → verified1.8.1
Updated•13 years ago
|
Flags: in-testsuite+ → in-testsuite?
Updated•13 years ago
|
Flags: blocking1.9a1?
Updated•9 years ago
|
Crash Signature: [@ js_FreeStack]
You need to log in
before you can comment on or make changes to this bug.
Description
•