Closed
Bug 315254
Opened 19 years ago
Closed 19 years ago
CVE-2006-1529 Crash [@ js_FreeStack] involving the unknown protocol error dialog
Categories
(Core :: Networking, defect)
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•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Reporter | ||
Comment 3•19 years ago
|
||
TB11505985Z
Assignee | ||
Comment 4•19 years ago
|
||
See also bug 315254.
Assignee | ||
Comment 5•19 years ago
|
||
Comment 6•19 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•19 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•19 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•19 years ago
|
||
Reporter | ||
Updated•19 years ago
|
Attachment #202177 -
Attachment mime type: text/plain → text/html
Updated•19 years ago
|
OS: MacOS X → All
Hardware: Macintosh → All
Comment 10•19 years ago
|
||
talkback: TB11693607G may be this
Assignee: darin → mrbkap
Comment 11•19 years ago
|
||
Probably exploitable given valgrind showing illegal memory writes
Group: security
Whiteboard: [sg:critical?]
Comment 12•19 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•19 years ago
|
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
Comment 13•19 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•19 years ago
|
Flags: blocking1.8.0.2? → blocking1.8.0.2+
Assignee | ||
Comment 14•19 years ago
|
||
I think the patch I just attached to bug 310508 will fix this bug as well.
Assignee | ||
Comment 15•19 years ago
|
||
This should now be fixed on trunk since the patch for bug 310508 is checked in.
Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•19 years ago
|
||
This is now fixed on the 1.8 branches (thanks to bug 310508).
Keywords: fixed1.8.0.2,
fixed1.8.1
Updated•19 years ago
|
Whiteboard: [sg:critical?] → [sg:critical?] Doesn't appear to affect ff1.0
Comment 17•19 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•19 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•19 years ago
|
Flags: in-testsuite+
Updated•19 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•19 years ago
|
Group: security
Comment 19•19 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•18 years ago
|
Flags: in-testsuite+ → in-testsuite?
Updated•18 years ago
|
Flags: blocking1.9a1?
Updated•14 years ago
|
Crash Signature: [@ js_FreeStack]
You need to log in
before you can comment on or make changes to this bug.
Description
•