1529167 - Unhandlable OOM results in Assertion Failure in the Non-developer Build Version of Spidermonkey

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Kame Wang]

Attachment: oom_20190218.js

My fuzzer has found a new bug on the latest sourcecode of https://github.com/mozilla/gecko-dev.git.
It will result in the crash of the js shell of Spidermonkey.

• Platform: Ubuntu 18.04

• Source code version: commit 7b9af4dfe5025d6f1531139bb711297d2a8e1ede.

• Build js shell commond:
  $ ${source_path}/configure
  $ make

• How to reproduce:
  $ ulimit -Sv 2097152
  $ ./dist/bin/js ./oom_20190218.js
  Assertion failure: [unhandlable oom] ConsumeBufferSource, at /home/kame/hdd-workspace/gecko-dev/js/src/vm/JSContext.cpp:1514
  Segmentation fault

• Tips:

1. The limit following "ulimit -Sv" should be larger than 1G (2G and 4G have been tested on my PC);
2. ./dist/bin/js is the path to output of building, ./oom_20190218.js is the attached file.

Comment 1

[Daniel Veditz [:dveditz]]

The bug bounty only covers actual shipping products like Firefox, not parts of the codebase like Spidermonkey. Can you reproduce this problem in a web page script?

Out of Memory bug also aren't covered by our bug bounty (they are considered Denial of Service bugs) unless the code mishandles the OOM condition and then does something bad (other than an immediate crash) following that.

Comment 2

[Kame Wang]

(In reply to Daniel Veditz [:dveditz] from comment #1)

The bug bounty only covers actual shipping products like Firefox, not parts of the codebase like Spidermonkey. Can you reproduce this problem in a web page script?

Out of Memory bug also aren't covered by our bug bounty (they are considered Denial of Service bugs) unless the code mishandles the OOM condition and then does something bad (other than an immediate crash) following that.

Hi, Deniel:

I haven't tested this bug in a web page script.
This is a OOM mishandle problem which only results in immediate crash.
Therefore, it is OK if there is no bounty for this.
I just wanted to report this bug to the Spidermonkey developers.

Thank you for your information.

Comment 3

[Jason Orendorff [:jorendorff]]

Kame Wang, Thank you for the detailed report.

This isn't a bug. Like other browsers, Firefox deliberately crashes on OOM. This kind of crash isn't exploitable—actually, it's a security feature: it's a way of immediately freeing system resources and making sure the process doesn't continue running after an unhandled failure. And for us as programmers, it eliminates a rare, non-deterministic error case that's hard to test thoroughly.

SpiderMonkey is a little different from the rest of Firefox; it usually throws an exception on OOM. But even in SpiderMonkey there are some places where we're doing something so critical that we can't just throw an exception and bail out. We crash instead. When SpiderMonkey does this, it prints [unhandlable oom].

Thanks again.

Marking "INVALID", which just means there's nothing to fix here.

Comment 4

[Kame Wang]

(In reply to Jason Orendorff [:jorendorff] from comment #3)

Kame Wang, Thank you for the detailed report.

This isn't a bug. Like other browsers, Firefox deliberately crashes on OOM. This kind of crash isn't exploitable—actually, it's a security feature: it's a way of immediately freeing system resources and making sure the process doesn't continue running after an unhandled failure. And for us as programmers, it eliminates a rare, non-deterministic error case that's hard to test thoroughly.

SpiderMonkey is a little different from the rest of Firefox; it usually throws an exception on OOM. But even in SpiderMonkey there are some places where we're doing something so critical that we can't just throw an exception and bail out. We crash instead. When SpiderMonkey does this, it prints [unhandlable oom].

Thanks again.

Marking "INVALID", which just means there's nothing to fix here.

Hi, Jason Orendorff:

Thank you very much for explaining the details.
Have a nice day.

Kame Wang