1509800 - Crash in js::gc::ClearEdgesTracer::clearEdge<T>

Status: RESOLVED DUPLICATE of bug 1494752

(Core :: JavaScript: GC, defect)

Description

[Gabriele Svelto [:gsvelto]]

This bug was filed from the Socorro interface and is
report bp-8476499e-0607-4e6d-901f-7816a0181126.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll js::gc::ClearEdgesTracer::clearEdge<JSString> js/src/gc/GC.cpp:9729
1 xul.dll DoCallback<JSString*> js/src/gc/Tracer.cpp:51
2 xul.dll js::FunctionScope::Data::trace js/src/gc/Marking.cpp:1260
3 xul.dll js::GCManagedDeletePolicy<js::FunctionScope::Data>::operator js/src/gc/DeletePolicy.h:80
4 xul.dll class mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::Scope::XDRSizedBindingNames<js::FunctionScope, js::XDR_DECODE> js/src/vm/Scope.cpp:302
5 xul.dll class mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::FunctionScope::XDR<js::XDR_DECODE> js/src/vm/Scope.cpp:782
6 xul.dll class mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRScript<js::XDR_DECODE> js/src/vm/JSScript.cpp:785
7 xul.dll class mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRInterpretedFunction<js::XDR_DECODE> js/src/vm/JSFunction.cpp:707
8 xul.dll class mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRScript<js::XDR_DECODE> js/src/vm/JSScript.cpp:904
9 xul.dll class mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRState<js::XDR_DECODE>::codeScript js/src/vm/Xdr.cpp:232

=============================================================

I would normally discount this signature as a problem with the user's machines because it affects the GC and the rate is low. However plenty of reports crash by reading from address 0xffffffffe5e5e5e4 which smells like an use-after-free. It might not be but it's better to double-check.

Comment 1

[Gabriele Svelto [:gsvelto]]

There's a few more interesting tidbits:

- Most of these crashes are on 32-bit hosts, but the minidumps contain a 64-bit address for the crash, this is most likely a bug in Breakpad or the associated crash-reporting machinery

- The real crashing address for 32-bit hosts is not 0xffffffffe5e5e5e4 but 0xe5e5e5e4 which is held in eax, I haven't looked at the code disassembly but it looks likely that's what is causing the failed read and there's a good chance that's an UAF

- On 64-bit hosts the crashing address is reported as 0xffffffffffffffff but rax contains 0xe5e5e5e5e5e5e5e4, most definitely an UAF, ouch

Comment 2

[Gabriele Svelto [:gsvelto]]

Note that the wrong address shown for 32-bit crashes is indeed a breakpad issue, I've opened bug 1509805 to fix it.

Comment 3

[Jon Coppeard (:jonco)]

I'm pretty sure this is bug 1494752.  Volume on beta has dropped to almost nothing since the fix landed there and the few crashes on nightly do not have the poison pattern as the address.