"Assertion failure: compartment mismatched" with InstallTrigger.constructor

RESOLVED FIXED in mozilla5

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: mrbkap)

Tracking

({assertion, testcase})

Trunk
mozilla5
x86
Mac OS X
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(status2.0 ?, status1.9.2 unaffected)

Details

(Whiteboard: [sg:critical?])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
Created attachment 519561 [details]
testcase (crashes Firefox when loaded)

Assertion failure: compartment mismatched, at js/src/jscntxtinlines.h:545
(Reporter)

Comment 1

7 years ago
Created attachment 519562 [details]
stack trace
(Reporter)

Comment 2

7 years ago
Reproduced with mozilla-central rev 4866be78732f and tracemonkey rev 67b102d581dd.
(Assignee)

Comment 3

7 years ago
Created attachment 519564 [details] [diff] [review]
Patch
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #519564 - Flags: review?(jst)
(Assignee)

Comment 4

7 years ago
Comment on attachment 519564 [details] [diff] [review]
Patch

oops, wrong bug.
Attachment #519564 - Attachment is obsolete: true
Attachment #519564 - Flags: review?(jst)
(Assignee)

Comment 5

7 years ago
Created attachment 519573 [details] [diff] [review]
Real patch

This was the easiest fix.
Attachment #519573 - Flags: review?(gal)

Updated

7 years ago
Attachment #519573 - Flags: review?(gal) → review+
Is this a compartment-leaking security bug (sg:high or worse), or just an oops? I don't crash in an opt build, is "testcase (crashes Firefox when loaded)" simply a fatal assert in a debug build?

Comment 7

7 years ago
I think this can cause problems during GC with compartment GCs. Based on that alone I would say sg:something.
(Assignee)

Comment 8

7 years ago
From talking to billm on IRC, operating on JS objects in the wrong compartment can cause us to collect reachable objects during GC. That's sg:critical. So, we should probably consider this as [sg:critical?]. Looking at the code, I'm not convinced that this case in particular is actually exploitable at all (and the result of the code that causes the assertion is thrown away anyway) but it's better to be safe than sorry.

Updated

7 years ago
Whiteboard: [sg:critical?]
(Assignee)

Comment 9

7 years ago
http://hg.mozilla.org/mozilla-central/rev/bed34ea0027c
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Per security group discussion, requesting landing on mozilla-2.0.
status2.0: --- → ?
Attachment #519573 - Flags: approval2.0?
Comment on attachment 519573 [details] [diff] [review]
Real patch

Approved for the mozilla2.0 repository, a=dveditz for release-drivers
Attachment #519573 - Flags: approval2.0? → approval2.0+
Group: core-security
status1.9.2: --- → unaffected
Target Milestone: --- → mozilla5
You need to log in before you can comment on or make changes to this bug.