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

Status: RESOLVED FIXED

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

Description

[Bob Clary [:bc] (inactive)]

Attachment: sample crash report

1. http://members.home.nl/bdr/files/fusker.html?http://members.home.nl/bdr/files/fusker.html%3Fhttp://i.crackedcdn.com/phpimages/photoshop/%5B1-9%5D/%5B1-9%5D/%5B1-9%5D/%5B1-9%5D%5B00-99%5D_slide.jpg

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.

Firefox/11
bp-9c5f6e84-81d0-49ff-83f4-385fd2120319
[@ EMPTY: no crashing thread identified; corrupt dump ] 

Nightly/14

bp-6d234ff4-7365-4282-8f8b-db3ca2120319
[@ 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 reason:  EXCEPTION_ACCESS_VIOLATION_EXEC
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.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Christian, can you run your OOM tool with this page and see if making certain allocations fail leads to badness?

Comment 2

[Christian Holler (:decoder)]

I'm testing this right now but it'll take a while until I can post possible results :)

Comment 3

[Daniel Veditz [:dveditz]]

Kyle: are you volunteering to take this bug? :-)

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

No.

Comment 5

[Johnny Stenback (:jst)]

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...

Comment 6

[Christian Holler (:decoder)]

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.

Comment 7

[Andrew McCreight [:mccr8]]

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

Comment 8

[Andrew McCreight [:mccr8]]

I'll wait to see if the other bug fixed this before investigating further.

Comment 9

[Bob Clary [:bc] (inactive)]

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.

Comment 10

[Andrew McCreight [:mccr8]]

Should we close/dupe this bug?

Comment 11

[Bob Clary [:bc] (inactive)]

lets call it fixed by bug 737875

Comment 12

[Daniel Veditz [:dveditz]]

bug 737875 has now been checked in to beta/aurora/esr10

Comment 13

[u279076]

As given by the testcase-wanted keyword, is there a testcase QA can use to verify this fix? Comment 0 perhaps?

Comment 14

[Bob Clary [:bc] (inactive)]

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.

Comment 15

[u279076]

(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.

Comment 16

[Al Billings [:abillings - ex-MoCo]]

Can this be verified through verification of bug 737875?

Comment 17

[Bob Clary [:bc] (inactive)]

(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.

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

calling this fixed as per comment 11, this was landed on 14 in bug 737875