Closed Bug 737129 Opened 13 years ago Closed 12 years ago

Possible Exploitable Crashes with Low Memory [@ nsiNodeInfo::NodeInfoManager ] with js::mjit::EnterMethodJIT on the stack


(Core :: DOM: Core & HTML, defect)

Windows XP
Not set



Tracking Status
firefox11 --- affected
firefox12 + fixed
firefox13 + fixed
firefox14 + fixed
firefox-esr10 12+ fixed


(Reporter: bc, Assigned: mccr8)




(Keywords: crash, reproducible, Whiteboard: [sg:critical][fixed by bug 737875][qa-])

Crash Data


(1 file)

Attached file sample crash report

2. Consume CPU and RAM until you crash

###!!! ASSERTION: Inserting node that already has parent: '!aKid->GetNodeParent()', file c:/work/mozilla/builds/nightly/mozilla/cont
ent/base/src/nsGenericElement.cpp, line 3757

Crashes Nightly/14, Aurora/13, Beta/12, Firefox/11 on Windows XP and Windows 7.

[@ EMPTY: no crashing thread identified; corrupt dump ] 


[@ EMPTY: no crashing thread identified; corrupt dump ] 

Operating system: Windows NT
                  6.1.7601 Service Pack 1
CPU: x86
     GenuineIntel family 6 model 37 stepping 1
     2 CPUs

Crash address: 0xffffffffb0fdfdfd

Thread 0 (crashed)
 0  0xb0fdfdfd
    eip = 0xb0fdfdfd   esp = 0x0052aba8   ebp = 0x0052abc4   ebx = 0x1f4bb790
    esi = 0x063479b0   edi = 0x04e605c0   eax = 0xff00a5f0   ecx = 0xdddddddd
    edx = 0xb0fdfdfd   efl = 0x00010286
    Found by: given as instruction pointer in context

Note the heap fenceposts 0xfd and the deleted memory. Other reports show 0xfeeefeee which is freed Heap memory from HeapFree. Common pattern in all reports so far is ecx = 0xdddddddd

Running under windbg I crash at [@ nsiNodeInfo::NodeInfoManager ]

More reports are available in Bughunter.
Christian, can you run your OOM tool with this page and see if making certain allocations fail leads to badness?
I'm testing this right now but it'll take a while until I can post possible results :)
Whiteboard: [sg:critical]
Kyle: are you volunteering to take this bug? :-)
Andrew says he can look into this. Tracking for 12 onwards, but whether we can fix this for 12 etc depends on what the fix ends up looking like...
Assignee: nobody → continuation
It is possible that this is fixed by bug 737875. The assertion here and the crash there both have "aKid" and I derived that crash from the testcase here using OOM testing. Since khuey has a fix for that bug, maybe bc can retest this once that fix landed.
The page is a script that creates a page with a bunch of inline images (656100 to be precise).  Running it on a bogus URL (so that it wasn't loading images at the same time) caused a lot of these:

WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /Users/amccreight/mz/cent3/content/base/src/nsGenericElement.cpp, line 3780
I'll wait to see if the other bug fixed this before investigating further.
I retested Beta/12, Aurora/13 and Nightly/14 in automation and only crashed in Windows 7 32 bit Beta/12, Aurora/13 and Nightly/14 without getting a crash dump. The last time Beta or Aurora showed an exploitable crash was 3/20 on Windows 7 64bit with 32bit builds.

Testing locally I only have seen oom aborts Windows XP 32bit and Windows 7 32bit Nightly/14. On Window 7 64bit (32bit builds) it just cranks along without crashing.

Testing locally with Aurora/Beta on Windows XP, I've seen the exploitable crashes with eax and ecx = 0xfeeefeee. Aurora/Beta on Windows 7 32bit only showed oom.

Not sure why automation didn't show the exploitable crashes on xp. Based on local testing I would say this is fixed on Nightly though. I haven't checked if the particular patch is responsible though.
Should we close/dupe this bug?
lets call it fixed by bug 737875
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical] → [sg:critical][fixed by bug 737875]
As given by the testcase-wanted keyword, is there a testcase QA can use to verify this fix? Comment 0 perhaps?
Whiteboard: [sg:critical][fixed by bug 737875] → [sg:critical][fixed by bug 737875][qa?]
The testcase-wanted was to ask someone to develop a reduced test case but I don't know if it is possible to get a reproducible one given the nature of these low/oom bugs.
(In reply to Bob Clary [:bc:] from comment #14)
> The testcase-wanted was to ask someone to develop a reduced test case but I
> don't know if it is possible to get a reproducible one given the nature of
> these low/oom bugs.

Given that we'll qa- this bug and put faith in crashstats data.
Whiteboard: [sg:critical][fixed by bug 737875][qa?] → [sg:critical][fixed by bug 737875][qa-]
Can this be verified through verification of bug 737875?
(In reply to Al Billings [:abillings] from comment #16)
> Can this be verified through verification of bug 737875?

I assert that to be the case, yes.
Group: core-security
calling this fixed as per comment 11, this was landed on 14 in bug 737875
You need to log in before you can comment on or make changes to this bug.