637226 - [CRASH] Malformed XML + DOM, Garbage Collector crash

Status: RESOLVED DUPLICATE of bug 602115

(Core :: XPConnect, defect)

Description

[Nils]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13

Description:
------------------------
A memory corruption occurs after several reloads of the attached testcase.
Most of the crashes are in the garbage collection routine and show exploitable
behaviour.

I was not able to reproduce the issues on Firefox 4 beta or Linux versions of Firefox 3. However following assertion was triggered on a debug build of Firefox 3 on Linux:

###!!! ASSERTION: Non-global object has the wrong flags: '!(jsclazz->flags & JSCLASS_IS_GLOBAL)', file ../../../../../js/src/xpconnect/src/xpcwrappednative.cpp, line 1114

Confirmed Versions:
------------------------
	Firefox 3.6.13

Testcase:
------------------------
Testcase is attached. You will need mal.xml in the same directory to reproduce the crash.

mal.xml:
<?xml-stylesheet type="text/xsl" href="x"?><x></x>

All other documents are embedded as data urls. Using a data url instead of mal.xml did not trigger the crash.

Testcase Notes:
------------------------
The testcase might need several reloads in the browser before triggering the crash.

Stack Backtrace:
------------------------

Windows:
(a94.1488): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
xul!WrappedNativeMarker+0xb:
68ea96fb 0fb74802        movzx   ecx,word ptr [eax+2]     ds:002b:deadbef1=????

xul!WrappedNativeMarker(struct JSDHashTable * table = 0x6f847bbc, struct JSDHashEntryHdr * hdr = 0x055dd180, unsigned long number = 0x730f80c, void * arg = 0x00000000)+0xb
js3250!JS_DHashTableEnumerate(struct JSDHashTable * table = 0x00000000, <function> * etor = 0x00000000, void * arg = 0x00000000)+0x6c
xul!XPCWrappedNativeScope::MarkAllWrappedNativesAndProtos(void)+0x21
xul!XPCJSRuntime::GCCallback(struct JSContext * cx = 0x006b223c, JSGCStatus status = 7021108 (No matching enumerant))+0x45
xul!DOMGCCallback(struct JSContext * cx = 0x6f88aab1, JSGCStatus status = 99048448 (No matching enumerant))+0x18
xul!jsds_GCCallbackProc(struct JSContext * cx = 0x6f88aab1, JSGCStatus status = 99048448 (No matching enumerant))+0x37
js3250!js_GC(struct JSContext * cx = 0x05e75c00, JSGCInvocationKind gckind = GC_LAST_DITCH (18))+0x3a3
js3250!NewGCThing<JSString>+0x5dd31


VulnDev reference	: vd11001

reported by nils of vulndev ltd.

Reproducible: Always

Steps to Reproduce:
1. Store attached crash.html and mal.xml in same directory
2. Load crash.html
3. crash
Actual Results:  
crash

Expected Results:  
no crash

Comment 1

[Nils]

Attachment: testcase (crash.html)

Comment 2

[Nils]

Attachment: testcase - part 2 (mal.xml)

Comment 3

[Johnny Stenback (:jst)]

Doesn't seem to happen on trunk.

Comment 4

[Johnny Stenback (:jst)]

I do see a bunch of:

WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file ../../../../../mozilla/content/xslt/src/xslt/txMozillaStylesheetCompiler.cpp, line 528

Jonas, can you have a look at this one?

Comment 5

[Nils]

I was not able to reproduce on 3.6.14, might have been fixed by one of the other patches.

Comment 6

[Daniel Veditz [:dveditz]]

Could not reproduce in 3.6.13 running on WinXP. Haven't tried Windows 7, might make a difference. Was also running in a VM which might also make a difference.

Comment 7

[Daniel Veditz [:dveditz]]

We fixed [sg:critical?] bug 602115 in Firefox 3.6.14, maybe this is the same?

Comment 8

[Marcia Knous [:marcia]]

I just tried reproducing this using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 and have not yet been able to trigger a crash, even after reloading the page several times.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, bug 602115 fixed error handling in several areas so it's entirely possible that it fixed this bug too.

However it's weird that that would cause the js assertion mentioned in comment 0.

Comment 10

[Nils]

I still get the assertion, follow by a warning:

###!!! ASSERTION: Non-global object has the wrong flags: '!(jsclazz->flags & JSCLASS_IS_GLOBAL)', file ../../../../../js/src/xpconnect/src/xpcwrappednative.cpp, line 1114
WARNING: Weird, we're finalized with a null language global?: file ../../../dom/base/nsGlobalWindow.cpp, line 2449

with Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.16pre) Gecko/20110303 Namoroka/3.6.16pre

downloaded from ftp://ftp.mozilla.org/pub/firefox/nightly/2011-03-03-03-mozilla-1.9.2-debug/firefox-3.6.16pre.en-US.debug-linux-i686.tar.bz2

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Over to xpconnect then.

Comment 12

[Daniel Veditz [:dveditz]]

mrbkap: is this remaining assertion a security problem? if so how bad?

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

I think I fixed that assertion in bug 638026. I don't think there's any security risk to it, though.

Comment 14

[Johnny Stenback (:jst)]

Nils, can you re-test this with a tracemonkey build now that bug 638026 landed there? Thanks!

Comment 15

[Daniel Veditz [:dveditz]]

nils: is this bug still reproducible on a tracemonkey (not mozilla-central) build?

Comment 16

[Nils]

I tested with tracemonkey debug build from

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/tracemonkey-linux-debug/1301577083/firefox-4.2a1pre.en-US.linux-i686.tar.bz2

and I don't see any assertions. However I am not sure whether the same result is expected from mozilla-1.9.2 + fix? What would be the easiest way to confirm that?

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

I don't know the answer to that question.

Comment 18

[Daniel Veditz [:dveditz]]

in bug 638026 comment 8 mrbkap says we don't need that fix on the 1.9.2 branch and the assertions are harmless. Since we've fixed the scary crash on the branch already I think we can let this bug go.