1372992 - Compartment mismatch in nsObjectLoadingContent::TeardownProtoChain()

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Andrew McCreight [:mccr8]]

This bug was filed from the Socorro interface and is 
report bp-6abdbf11-7136-40db-a0cd-0619f0170609.
=============================================================

This crash is a compartment mismatch for the JS_GetPrototype call in nsObjectLoadingContent::TeardownProtoChain(). I'm guessing that the prototype chain crosses compartments, but we don't enter the new compartment. I don't know how exploitable this is.

Comment 1

[Benjamin Smedberg]

In what cases can a proto chain cross compartments?

Overholt I need the DOM team to own triage on this: I don't know enough about JSAPI to make a good decision.

Comment 2

[Andrew McCreight [:mccr8]]

Boris, is a cross-compartment proto chain something that can happen?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> I'm guessing that the prototype chain crosses compartments

That should never happen.  In particular, JS_SetPrototype asserts that obj and proto are same-compartment, and object creation with a given proto asserts that the proto is same-compartment with cx (and the new object get created in the compartment of cx).

I don't see any operation on unwrapped objects in the TeardownProtoChain code (apart from the nsNPObjWrapper::IsWrapper(js::UncheckedUnwrap(proto)) bit, but that doesn't change any local state), so I don't see how we could end up with a compartment mismatch here unless something is _really_ broken somewhere... :(

Comment 4

[Andrew McCreight [:mccr8]]

Thanks for looking, Boris. This could just be generic memory corruption, then. I only see a single crash like this, so I'll just close this as incomplete for now.