Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0," or "Assertion failure: !unknownProperties(),"

VERIFIED FIXED in Firefox 17

Status

()

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

People

(Reporter: gkw, Assigned: shu)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla17
x86_64
Mac OS X
assertion, regression, sec-critical, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox14 unaffected, firefox15 unaffected, firefox16 unaffected, firefox17 verified, firefox-esr10 unaffected)

Details

(Whiteboard: [fuzzblocker][adv-track-main17-], crash signature)

Attachments

(5 attachments)

(Reporter)

Description

6 years ago
Created attachment 653226 [details]
stack

ParallelArray(/x/, /x/);

asserts js debug shell on m-c changeset 35b8d6ef5d46 without any CLI arguments at Assertion failure: dimensions.length() > 0,

Another [fuzzblocker] similar to bug 783923.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   102665:ea2ad8970f3e
user:        Shu-yu Guo
date:        Fri Aug 17 10:38:59 2012 -0700
summary:     Bug 778559 - Implement ParallelArray API with sequential execution (r=dmandelin)
(Reporter)

Updated

6 years ago
Group: core-security
(Reporter)

Comment 1

6 years ago
Created attachment 653227 [details]
stack from opt crash

I just rechecked, this is very bad, 0xffffffff is being accessed.
(Reporter)

Updated

6 years ago
status-firefox-esr10: --- → unaffected
status-firefox14: --- → unaffected
status-firefox15: --- → unaffected
status-firefox16: --- → unaffected
status-firefox17: --- → affected
Keywords: sec-critical
(Reporter)

Updated

6 years ago
Crash Signature: [@ js::ParallelArrayObject::IndexInfo::initialize]
Summary: "Assertion failure: dimensions.length() > 0," → Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0,"
(Reporter)

Comment 2

6 years ago
Created attachment 653231 [details]
stack

One more testcase:

Function("ParallelArray([])")()

Assertion failure: !unknownProperties(),
(Assignee)

Comment 3

6 years ago
Created attachment 653234 [details] [diff] [review]
fix for dimensions.length() > 0 assert
(Assignee)

Comment 4

6 years ago
Created attachment 653235 [details] [diff] [review]
fix for !unknownProperties() assert
(Assignee)

Comment 5

6 years ago
Note that the fix for !unknownProperties() patch requires patch in bug 783923 to be already applied.
(Assignee)

Updated

6 years ago
Attachment #653234 - Flags: review?
(Assignee)

Updated

6 years ago
Attachment #653235 - Flags: review?
(Assignee)

Updated

6 years ago
Attachment #653234 - Flags: review? → review?(dmandelin)
(Assignee)

Updated

6 years ago
Attachment #653235 - Flags: review? → review?(dmandelin)
(Assignee)

Comment 6

6 years ago
Comment on attachment 653235 [details] [diff] [review]
fix for !unknownProperties() assert

Actually, this makes more sense to be reviewed by bhackett.
Attachment #653235 - Flags: review?(dmandelin) → review?(bhackett1024)
(Reporter)

Updated

6 years ago
Summary: Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0," → Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0," or "Assertion failure: !unknownProperties(),"
Attachment #653234 - Flags: review?(dmandelin) → review+
Attachment #653235 - Flags: review?(bhackett1024) → review+
https://hg.mozilla.org/mozilla-central/rev/6087ddaf9911
https://hg.mozilla.org/mozilla-central/rev/f6ff05c68a61
Assignee: general → shu
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
status-firefox17: affected → fixed
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
status-firefox17: fixed → verified
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #1)
> I just rechecked, this is very bad, 0xffffffff is being accessed.

If %rax is always null then it doesn't really matter where the other address is, it's still going to crash before it does anything nasty. Is it always null? That seems to be the case the patch is protecting against.
Depends on: 783923
(Reporter)

Comment 11

6 years ago
The instruction at %pc register is: movl   $0x1,(%rax,%rcx,4)

Does this mean storing 0x1 at %rax and %rcx, not accessing %rax and %rcx themselves?

Updated

6 years ago
Whiteboard: [fuzzblocker] → [fuzzblocker][adv-track-main17-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.