799438 - IonMonkey: AddressSanitizer heap-use-after-free in [@ js::StackSegment::popCall] or Assertion failure: !used(), at ../ion/shared/Assembler-shared.h:234

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase triggers an ASan error on mozilla-central revision 9738e5a0190a (requires --ion-eager):


var lfcode = new Array();
lfcode.push("\
gcparam(\"maxBytes\", gcparam(\"gcBytes\") + 4*1024);\
function f() {}\
function g(n, h) {\
    var t = g( \"x\"    ) ;\
    return a(h(function() { return t(); }));\
}\
g(80, f);\
");
delete Debugger;
evaluate(lfcode[0]);


A less reduced test yielded an assertion instead in a debug build, but reducing that version further did not show the use-after-free anymore on opt builds:


var lfcode = new Array();
lfcode.push("try {\
gcparam(\"maxBytes\", gcparam(\"gcBytes\") + 4*1024);\
arr = [1e0, 5e1, 9e19, 0xDd , 1.3e20, 1e20, 9e20, 9.99e20, \
    0.1e21, 1e21, reportCompare   +  this       , 1e21+65536, 1e21-65536, 1]; \
    } catch(exc1) {}\
");
lfcode.push("function f() {}\
function g(n, h) {\
    var t = g( \"x\" ) ;\
}\
g(80, f);\
");
while (true) {
  var file = lfcode.shift(); if (file == undefined) { break; }
  loadFile(file);
}
function loadFile(lfVarx) {
        try {
                if (lfVarx.substr(-3) == ".js") {} else {
                        evaluate(lfVarx);
                }
        } catch (lfVare) {}
}


ASan trace:

==24272== ERROR: AddressSanitizer heap-use-after-free on address 0x7f6f3a55f690 at pc 0x91fcd0 bp 0x7fffb2273260 sp 0x7fffb2273258
READ of size 8 at 0x7f6f3a55f690 thread T0
    #0 0x91fccf in js::StackSegment::popCall() /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/vm/Stack.cpp:544
    #1 0x7f6f3b8c5c10 in  
0x7f6f3a55f690 is located 16 bytes inside of 128-byte region [0x7f6f3a55f680,0x7f6f3a55f700)
freed by thread T0 here:
    #0 0xf7d810 in __interceptor_free ??:0
    #1 0xc90b3b in js_free /srv/repos/mozilla-central/js/src/opt64asan/./dist/include/js/Utility.h:170
    #2 0x7f6f3b8c55aa in  
    #3 0xc9d047 in EnterIon(JSContext*, js::StackFrame*, void*) /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/ion/Ion.cpp:1368
    #4 0x5e0f74 in js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsinterp.cpp:2490
    #5 0xc90748 in js::ion::ThunkToInterpreter(JS::Value*) /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/ion/Bailouts.cpp:646
    #6 0x7f6f3b8c5c10 in  
previously allocated by thread T0 here:
    #0 0xf7d8d0 in malloc ??:0
    #1 0xc8cccd in js_malloc /srv/repos/mozilla-central/js/src/opt64asan/./dist/include/js/Utility.h:153
    #2 0xc8e34b in js::ion::InvalidationBailout(js::ion::InvalidationBailoutStack*, unsigned long*) /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/ion/Bailouts.cpp:391
    #3 0x7f6f3b8c5407 in  
    #4 0xc9d047 in EnterIon(JSContext*, js::StackFrame*, void*) /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/ion/Ion.cpp:1368
    #5 0x5e0f74 in js::Interpret(JSContext*, js::StackFrame*, js::InterpMode) /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/jsinterp.cpp:2490
    #6 0xc90748 in js::ion::ThunkToInterpreter(JS::Value*) /home/ownhero/homes/mozilla/repos/mozilla-central/js/src/ion/Bailouts.cpp:646
    #7 0x7f6f3b8c5c10 in

Comment 1

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 47876c1d1c45).

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   110418:741fb7f8e5cb
user:        Terrence Cole
date:        Wed Sep 26 11:13:20 2012 -0700
summary:     Bug 793577 - Implement Return<T> for direct returns of unrooted GC pointers; r=billm r=njn

This iteration took 86.913 seconds to run.

Comment 3

[Terrence Cole [:terrence]]

Seems extremely unlikely, but I'll take a look.

Comment 4

[Christian Holler (:decoder)]

Since the test doesn't reproduce anymore (just tried with ASan) and jandem says that js::StackSegment::popCall is no longer in the codebase, could this still be an issue? Terrence, if you think this isn't worth investigating anymore, let's just close it as WFM :)

Comment 5

[Terrence Cole [:terrence]]

Yeah, I never made much progress with this: it was low priority since it didn't repro on tip and the use of gcMaxBytes made me think it would be hard to exploit even if still present. If Jan says the code is gone now anyway, lets just close this.