905993 - Dangerous Crash on Heap (reproduces only cleanly on ASan)

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 1ed5a88cd4d0 (run with --fuzzing-safe --ion-eager):


Object.prototype[(0)] = 3;
var N = 1 << 16;
var array = Array(50);
for (var i = 0; i != N/2; ++i)
  array[i] = i;

Comment 1

[Christian Holler (:decoder)]

Since approximately August 05, I am seeing random crashes on the heap on all fuzzers. Unfortunately, none of these reproduce cleanly, they reproduce in 1% of all runs and are very hard to reduce and long running.

Fortunately, it seems that on the ASan builds, I've found the same bug, just that it reproduces quicker and more cleanly. This *could* be due to different memory layout/initialization that ASan chooses. The crash looks like this:


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e8e15a in ?? ()
(gdb) bt
#0  0x00007ffff7e8e15a in ?? ()
#1  0x00007ffff7e81564 in ?? ()
#2  0x0000000000000183 in ?? ()
#3  0x00007ffff6855101 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb) x /i $pc
=> 0x7ffff7e8e15a:      mov    %edx,(%rbx,%rbx,8)
(gdb) info reg rbx
rbx            0x609a00000210   106214541230608
(gdb) info reg edx
edx            0x641    1601


On the non-ASan slaves, the crashes looked the same, in particular the register pattern. Jandem mentioned that the register pattern here might be characteristic for the bug.

Marking this at least sec-high for now.

Comment 2

[Jan de Mooij [:jandem]]

Regression from bug 900890, which was backported to aurora and beta a few days ago.

Comment 3

[Jan de Mooij [:jandem]]

Attachment: Patch

One-liner.

Comment 4

[Jan de Mooij [:jandem]]

Comment on attachment 791255 [details] [diff] [review]
Patch

> [Security approval request comment]
> How easily could an exploit be constructed based on the patch?

Not trivial, but it's doable for somebody who knows what he's doing.

> Do comments in the patch, the check-in comment, or tests included
> in the patch paint a bulls-eye on the security problem?

No.

> Which older supported branches are affected by this flaw?

Bug 900890 was backported to aurora and beta a few days ago, so aurora and beta are affected too.

> If not all supported branches, which bug introduced the flaw?

Bug 900890.

> Do you have backports for the affected branches? If not, how different,
> hard to create, and risky will they be?

Should apply to older branches, just a one-liner.

> How likely is this patch to cause regressions; how much testing does it need?

Unlikely, and it should only affect 64-bit.

Comment 5

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 791255 [details] [diff] [review]
Patch

sec-approval+ for trunk.

Once it is there, it is approved for beta and aurora. Let's try to avoid shipping the problem behavior. Please get this in soon so it gets released in a few betas.

Comment 6

[Jan de Mooij [:jandem]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a3788b319566

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a3788b319566

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3c47be93883e
https://hg.mozilla.org/releases/mozilla-beta/rev/0cb473e88100