Assertion failure: cx->runtime->gcNumber == gcNumberBefore, at js/src/vm/RegExpObject.cpp:655

VERIFIED FIXED in Firefox 13

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: decoder, Assigned: luke)

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
mozilla13
x86_64
Linux
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox12 unaffected, firefox13 fixed, firefox-esr10 unaffected, status1.9.2 unaffected)

Details

(Whiteboard: [sg:critical] js-triage-done [advisory-tracking+])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 601259 [details]
Test case for shell (see README file inside).

The attached test asserts on mozilla-central revision 2dc40eb83023 (see README for running instructions).

The test does not crash when stepping through the assert, but trips other dangerous assertions:

Program received signal SIGABRT, Aborted.
Assertion failure: mutationCount == p.mutationCount, at ./dist/include/js/HashTable.h:688

Program received signal SIGABRT, Aborted.
Assertion failure: !p.found(), at ./dist/include/js/HashTable.h:690

I assume it's some form of memory corruption (test is also fragile). S-s for that.
(Assignee)

Comment 1

6 years ago
Mmm fuzzing + strong assertions.  I thought I had verified that RegExpShared::compile didn't do any GC-thing allocation but I must have been looking at RegExpCode::compile b/c RegExpShare::compile clearly allocates an atom.
Assignee: general → luke
Whiteboard: js-triage-needed → js-triage-done
(Assignee)

Comment 2

6 years ago
There is a pretty simple reproducible test case:

  gczeal(2,1);
  /a/y.exec('a')

The '1' arg tells GC to start GC'ing on every allocation immediately (instead of waiting for a while).  Perhaps the fuzzers could be souped up to use this?
(Assignee)

Comment 3

6 years ago
Created attachment 601412 [details] [diff] [review]
patch

Remove those filthy lies.
Attachment #601412 - Flags: review?(wmccloskey)
Comment on attachment 601412 [details] [diff] [review]
patch

Yeah, this just looks better all around.
Attachment #601412 - Flags: review?(wmccloskey) → review+

Comment 5

6 years ago
jsfunfuzz should generate gczeal(2, 1) fairly often. (How is that different from gczeal(2))?
(Assignee)

Comment 6

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/2742bfe821d2
Target Milestone: --- → mozilla13

Comment 7

6 years ago
https://hg.mozilla.org/mozilla-central/rev/2742bfe821d2
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
status-firefox13: --- → fixed
I assume GC things can be exploited (e.g. the Pwn2Own bug). Since this is a regression from bug 724748 we don't need it anywhere other than Fx13
Blocks: 724748
Group: core-security
status1.9.2: --- → unaffected
status-firefox-esr10: --- → unaffected
status-firefox12: --- → unaffected
Keywords: regression
Whiteboard: js-triage-done → [sg:critical] js-triage-done
(Reporter)

Updated

6 years ago
Status: RESOLVED → VERIFIED
Whiteboard: [sg:critical] js-triage-done → [sg:critical] js-triage-done [advisory-tracking+]
(Reporter)

Comment 9

5 years ago
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/testBug731181.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.