Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
--
critical
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: bc, Assigned: mccr8)

Tracking

(Blocks: 1 bug, {crash, reproducible})

Trunk
x86
Windows XP
crash, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox11 affected, firefox12+ fixed, firefox13+ fixed, firefox14+ fixed, firefox-esr1012+ fixed)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 607258 [details]
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.
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 :)
Blocks: 737875
Whiteboard: [sg:critical]
Kyle: are you volunteering to take this bug? :-)
status-firefox-esr10: --- → affected
status-firefox11: --- → affected
status-firefox12: --- → affected
status-firefox13: --- → affected
status-firefox14: --- → affected
Keywords: testcase-wanted
No.
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
tracking-firefox12: --- → +
tracking-firefox13: --- → +
tracking-firefox14: --- → +
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.
(Assignee)

Comment 7

5 years ago
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
(Assignee)

Comment 8

5 years ago
I'll wait to see if the other bug fixed this before investigating further.
(Reporter)

Comment 9

5 years ago
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.
(Assignee)

Comment 10

5 years ago
Should we close/dupe this bug?
(Reporter)

Comment 11

5 years ago
lets call it fixed by bug 737875
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical] → [sg:critical][fixed by bug 737875]
bug 737875 has now been checked in to beta/aurora/esr10
status-firefox-esr10: affected → fixed
status-firefox12: affected → fixed
status-firefox13: affected → fixed
tracking-firefox-esr10: --- → 12+
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?]
(Reporter)

Comment 14

5 years ago
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?
(Reporter)

Comment 17

5 years ago
(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
status-firefox14: affected → fixed
calling this fixed as per comment 11, this was landed on 14 in bug 737875
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.