Mats Palmgren (inactive) Assignee
	Description • 14 years ago

The "mLayerManager->Destroy()" call in nsWindow::Destroy() leads to accessing
a deallocated frame.
http://hg.mozilla.org/mozilla-central/diff/f7c05b60f1cc/widget/src/gtk2/nsWindow.cpp

PREPARATIONS
1. build Firefox with --enable-valgrind etc.
2. download cross_fuzz v3 from http://lcamtuf.coredump.cx/cross_fuzz/

STEPS TO REPRODUCE
1. mkdir PROFILE
2. firefox -no-remote -profile PROFILE
    * in Preferences->Content, disable pop-up blocking
    * in Preferences->Advanced->Update, disable all updates
    * in Preferences->Privacy->History to "Never remember history"
    * in about:config
        - set javascript.options.methodjit.content to false
        - set javascript.options.methodjit.chrome to false
3. quit
4. firefox -g --debugger valgrind -no-remote -profile PROFILE \
     "file:///CROSS_FUZZ_PATH/cross_fuzz_randomized_20110105_seed.html#139139139"
5. let it run until the "slow script" dialog appears:
     click the "Don't show this dialog again" checkbox
     click "Continue"
     when the dialog closes ==> BUG

ACTUAL RESULT
see attachment

	Daniel Veditz [:dveditz]
	Comment 1 • 14 years ago

Looks like this one bypasses frame-poisoning, deleted "this" in call to nsIFrame::GetStyleContext()

	Johnny Stenback (:jst)
	Comment 2 • 14 years ago

Marking this a blocker per above comments.

	David Baron :dbaron:
	Comment 3 • 14 years ago

(In reply to comment #1)
> Looks like this one bypasses frame-poisoning, deleted "this" in call to
> nsIFrame::GetStyleContext()

Mats certainly had frame poisoning disabled (because the frame arena was disabled) for the "valgrind log" part of the above, and possibly for all of it.

	David Baron :dbaron:
	Comment 4 • 14 years ago

Bug 625249 is similar, I think.

	Mats Palmgren (inactive) Assignee
	Comment 5 • 14 years ago

> Mats certainly had frame poisoning disabled

Yes, the relevant mozconfig options for this build:
ac_add_options --enable-optimize="-fno-omit-frame-pointer -fno-asynchronous-unwind-tables -fno-inline -O -g -ggdb -DDEBUG_TRACEMALLOC_PRESARENA"
ac_add_options --enable-debug
ac_add_options --disable-jemalloc
ac_add_options --enable-valgrind

I'm pretty sure it's mitigated by frame poisoning in a default build.

	Mats Palmgren (inactive) Assignee
	Comment 6 • 14 years ago

I don't think this needs to block 2.0 since it's mitigated by frame poisoning
in a release build.  I think it's unlikely to occur under normal circumstances,
i.e. when not running a fuzzer.

	Johnny Stenback (:jst)
	Comment 7 • 14 years ago

Removing sg: marking to trigger a re-triage based on the most recent comments.

	Daniel Veditz [:dveditz]
	Comment 8 • 14 years ago

(In reply to comment #6)
> I think it's unlikely to occur under normal circumstances,
> i.e. when not running a fuzzer.

Attackers run fuzzers; just because random users aren't likely to be crashing left and right doesn't make it less of a potential security problem (if it is one, which in this case sounds like it isn't).

	Mats Palmgren (inactive) Assignee
	Comment 9 • 14 years ago

What I meant with the second sentence is that the non-security aspects of
the crash (potential dataloss, annoyance etc) isn't a problem since the
crash is unlikely to occur.

	Daniel Veditz [:dveditz]
	Comment 10 • 12 years ago

Is this still a problem in current builds?

	Ryan VanderMeulen [:RyanVM]
	Comment 11 • 7 years ago

(In reply to Daniel Veditz [:dveditz] from comment #10)
> Is this still a problem in current builds?

	Mats Palmgren (inactive) Assignee
	Comment 12 • 7 years ago

No crash, but I'm seeing a lot of assertions.  I'll report them separately.
I'm guessing no one runs this old fuzzer on a regular basis... :-(