1001216 - heap-use-after-free in PushMarkStack

Status: RESOLVED INCOMPLETE

(Core :: JavaScript: GC, defect)

Description

[Tyson Smith [:tsmith]]

Attachment: asan_stack_trace.txt

Found by the BlackBerry Security Automated Analysis Team's fuzzing framework ALF.

At this time we are unable to create a test case that will reproduce the issue. 

==7340==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f0f08efe6d8 at pc 0x7f0f37b4489b bp 0x7fff1c0255f0 sp 0x7fff1c0255e8
READ of size 8 at 0x7f0f08efe6d8 thread T0
    #0 0x7f0f37b4489a (libxul.so!PushMarkStack(js::GCMarker*, js::BaseShape*)+0x107a)
    Line 705 of "/builds/slave/m-in-l64-asan-0000000000000000/build/js/src/gc/Heap.h"
    #1 0x7f0f37b44fcf (libxul.so!PushMarkStack(js::GCMarker*, js::Shape*)+0x14f)
    Line 981 of "/builds/slave/m-in-l64-asan-0000000000000000/build/js/src/gc/Marking.cpp"
    #2 0x7f0f37afd96a (libxul.so!js::GCMarker::processMarkStackTop(js::SliceBudget&)+0x68a)
    Line 1539 of "/builds/slave/m-in-l64-asan-0000000000000000/build/js/src/gc/Marking.cpp"
    #3 0x7f0f37afd26b (libxul.so!js::GCMarker::drainMarkStack(js::SliceBudget&)+0xeb)
    Line 1606 of "/builds/slave/m-in-l64-asan-0000000000000000/build/js/src/gc/Marking.cpp"
    #4 0x7f0f383cae5d (libxul.so!EndMarkingZoneGroup(JSRuntime*)+0x4dd)
    Line 3252 of "/builds/slave/m-in-l64-asan-0000000000000000/build/js/src/jsgc.cpp"
    #5 0x7f0f383c53fb (libxul.so!IncrementalCollectSlice(JSRuntime*, long, JS::gcreason::Reason, js::JSGCInvocationKind)+0x4c9b)
    Line 4094 of "/builds/slave/m-in-l64-asan-0000000000000000/build/js/src/jsgc.cpp"
...

Comment 1

[Tyson Smith [:tsmith]]

Attachment: asan_stack_trace_2.txt

Comment 2

[Daniel Veditz [:dveditz]]

oh boy... without a testcase it's pretty hard to figure out what's getting freed :(

Comment 3

[Andrew McCreight [:mccr8]]

Terrence, these stacks might actually be interesting.  It looks like rekeying of hashtables is involved.  It looks like the CC is freeing something in a hashtable, then the GC touches it later, which is weird.  The initial allocation is also inside the CC.

Comment 4

[Terrence Cole [:terrence]]

Comment on attachment 8412264 [details]
asan_stack_trace_2.txt

Filed bug 1004215 for this.

Comment 5

[Terrence Cole [:terrence]]

It should not be possible for that memory to wind up in the mark stack or reachable from anything in the mark stack. Andrew is pushing types through that bit of the CC code right now, just to be sure we don't have any typo-like mistakes with calling the markers on something totally invalid.

Comment 6

[Andrew McCreight [:mccr8]]

The first stack is super bizarre.  It looks like the GC is tracing the (former) location of the CC's internal hash table.  I'm not even sure how pointers to it can leak out of the cycle collector.  I'd think that the most likely cause is some kind of wild pointer, but the GC and CC are intertwined enough I could imagine scenarios where a bug in the CC could cause that.  Terrence and I talked about it, but we didn't come up with any leads that panned out so far.

Comment 7

[Andrew McCreight [:mccr8]]

I'll think about where this could go wrong for a bit.

Comment 8

[Jan de Mooij [:jandem]]

(In reply to Andrew McCreight [:mccr8] from comment #6)
> I'm not even sure how
> pointers to it can leak out of the cycle collector.  I'd think that the most
> likely cause is some kind of wild pointer,

Bug 1004215 also looks like a wild pointer..

Comment 9

[Daniel Veditz [:dveditz]]

see also bug 984361 for a top-crash in the same function

Comment 10

[Andrew McCreight [:mccr8]]

I'm going mark this incomplete, as we have nothing to go one here.