727987 - Assertion failure: obj, at ../../jsval.h:774 or Crash on heap (JIT) or Crash [@ js::gc::ChunkBitmap::markIfUnmarked] with OOM

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test asserts/crashes on mozilla-central revision 4a9a6ffd1f21:

gcparam("maxBytes", gcparam("gcBytes") + 4*(1));
arr = [1e0, 5e1, 9e19, 0.1e20, 1.3e20, 1e20, 9e20, 9.99e20, 
    0.1e21, 1e21, 1e21+65537, 1e21+65536, 1e21-65536, 1]; 
for (var i = 0; i < 4000; i++) {
    arr.push(new Boolean(false));
}


When stepping through the assert, I first got this crash with options -m -n:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f3fcd9 in ?? ()
(gdb) bt
#0  0x00007ffff7f3fcd9 in ?? ()
#1  0x00007ffff7f3fc2e in ?? ()
#2  0x0000000000000001 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) x /4i $pc
=> 0x7ffff7f3fcd9:      mov    0x8(%rsi),%rsi
   0x7ffff7f3fcdd:      movabs $0x7ffff6000250,%r11
   0x7ffff7f3fce7:      cmp    %r11,%rsi
   0x7ffff7f3fcea:      je     0x7ffff7f3fcf5
(gdb) info register rsi
rsi            0x0      0


This looked like a simple null-deref. However, without any options, I get this crash:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004b9dcc in js::gc::ChunkBitmap::markIfUnmarked (this=0xfc0b8, cell=0x0, color=0) at /srv/repos/larch/js/src/jsgc.h:666
666             if (*word & mask)
(gdb) x / 4i $pc
Invalid number "4i".
(gdb) x /4i $pc
=> 0x4b9dcc <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+58>:    mov    (%rax),%rdx
   0x4b9dcf <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+61>:    mov    -0x10(%rbp),%rax
   0x4b9dd3 <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+65>:    and    %rdx,%rax
   0x4b9dd6 <js::gc::ChunkBitmap::markIfUnmarked(js::gc::Cell const*, uint32_t)+68>:    test   %rax,%rax
(gdb) info register rax rdx
rax            0xfc0b8  1032376
rdx            0xfc0b8  1032376


which is certainly security-relevant. I can't judge if you can get the non-jitted crash in the browser somehow, so I'm marking this s-s.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

It's an OOM.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Also, we'll always crash at exactly the same address that Christian saw (0xfc0b8). I'm not sure what the security implications of that are. It seems possible that there could be important stuff there, and we're going to set a bit on that word. But I think an attacker would have to be pretty clever to exploit this.

Comment 3

[Christian Holler (:decoder)]

Heh, I'm just afraid once I see "gc" with a crash and a non-null address ^_^

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/24dd2472229f

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/mozilla-central/rev/24dd2472229f

Comment 6

[Daniel Veditz [:dveditz]]

This is a regression from bug 695756 so it affects the ESR, though it doesn't seem needed.

Comment 7

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.