Closed Bug 966490 Opened 7 years ago Closed 7 years ago

Crashes in js::ObjectImpl::getClass() under WeakMap::keyNeedsMark with poisoned GC pointer


(Core :: JavaScript Engine, defect)

Not set



Tracking Status
firefox27 --- ?
firefox28 --- affected
firefox29 --- ?


(Reporter: jandem, Unassigned)



(Keywords: csectype-uaf, sec-critical)

Crash Data

I was looking at Aurora crashes for another bug and noticed we have a topcrash there in js::ObjectImpl::getClass() and most of the stacks are like this:

- js::ObjectImpl::getClass()
- js::WeakMap<js::EncapsulatedPtr..snip..>::keyNeedsMark(JSObject *)
- js::WeakMap<js::EncapsulatedPtr<..snip..>::markIteratively(JSTracer *)
- MarkWeakReferences<js::CompartmentsIterT<js::gc::GCZoneGroupIter> >

See for instance:

We crash because we're accessing a bogus pointer: 0xdadadada. I opened a few reports and these also all had IncrementalCollectSlice on the stack.

Bill, Terrence: long shot but does anything about WeakMap marking on Aurora stand out to you? This seems to only affect Aurora; maybe a fix for some related bug went into 29?
One random guess is that exact rooting is on in 29 but not 28...
Terrence, any thoughts on comment 0 or comment 1?
Flags: needinfo?(terrence)
Exact rooting doesn't really interact directly with weak marking. It changes the liveness graph, but not in any way that should impact this sort of crash directly. IIRC, we've had a persistent small volume of crashes on dead weakmap keys under various signatures basically forever with seemingly random spikes up and down.

A dead key would probably indicate that sweeping the table failed or didn't happen. Maybe Jon or Steve can think of something more relevant here?
Flags: needinfo?(terrence)
Flags: needinfo?(sphink)
Flags: needinfo?(jcoppeard)
Can anyone take this and get 'er done?
I don't think anyone knows what the problem is. It looks like we have a dead weakmap key, but it's not clear why.
Still no stacks in 29+...
Group: javascript-core-security
This only ever showed up on 29, and I don't even see it there in the top 50 crashes now, so I think there's not much else we can do here.  Please reopen if we get more information.
Closed: 7 years ago
Flags: needinfo?(sphink)
Flags: needinfo?(jcoppeard)
Resolution: --- → INCOMPLETE
I'm reopening this because it looks really similar to the crash in bug 984101, which is a 1.3T blocker.  1.3 is based on Firefox 28.  There's not a lot to go on here, but maybe we have historical crash stats datae that could provide some information?

Kairo, is there some way we could figure out the history of this crash signature on 28 and 29?  Like, maybe it went away from the top 50 crashes on some particular day on 28, and on some other day for 29?  That might be useful to figure out what if anything resolved this problem.
Blocks: 984101
Crash Signature: [@ js::ObjectImpl::getClass() ]
Flags: needinfo?(kairo)
Resolution: INCOMPLETE → ---
(In reply to Andrew McCreight [:mccr8] from comment #8)
> Kairo, is there some way we could figure out the history of this crash
> signature on 28 and 29?

Unfortunately I do not have an easy way to do that at this time.
Flags: needinfo?(kairo)
Closed: 7 years ago7 years ago
Resolution: --- → INCOMPLETE
Group: javascript-core-security
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.