727333 - JS OOM Testing: Assertion failure: !entered && i < mLength, at ./dist/include/js/Vector.h:373 or Crash [@ JSC::Yarr::YarrGenerator::opCompileBody]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following command crashes/asserts on mozilla-central revision d45c7d7b0079:

js -m -n -a -A 1076 -f js/src/tests/shell.js -f js/src/tests/js1_7/shell.js -f js/src/tests/js1_7/geniter/shell.js -f js/src/tests/js1_7/geniter/regress-349331.js


Stepping through assertion yields this crash:

Program received signal SIGSEGV, Segmentation fault.
0x000000000075b07a in JSC::Yarr::YarrGenerator::opCompileBody (this=0x7fffffff73d0, disjunction=0xb65f60) at /home/decoder/LangFuzz/mozilla-central/js/src/yarr/YarrJIT.cpp:2317
2317            ASSERT(lastOp.m_op == OpBodyAlternativeNext);
(gdb) x /4i $pc
=> 0x75b07a <JSC::Yarr::YarrGenerator::opCompileBody(JSC::Yarr::PatternDisjunction*)+1514>:     movl   $0x0,(%rax)
   0x75b080 <JSC::Yarr::YarrGenerator::opCompileBody(JSC::Yarr::PatternDisjunction*)+1520>:     mov    $0x0,%eax
   0x75b085 <JSC::Yarr::YarrGenerator::opCompileBody(JSC::Yarr::PatternDisjunction*)+1525>:     callq  *%rax
   0x75b087 <JSC::Yarr::YarrGenerator::opCompileBody(JSC::Yarr::PatternDisjunction*)+1527>:     mov    -0x3f8(%rbp),%rax
(gdb) info register rax
rax            0xbbadbeef       3148725999


S-s because the crash is an internal debug-only YARR abort, possibly with security impact in opt builds.

Comment 1

[Christian Holler (:decoder)]

I removed the YARR abort by commenting out the crash code for 0xbbadbeef and got this crash:

Program received signal SIGSEGV, Segmentation fault.
0x000000000074c32f in JSC::Yarr::ByteCompiler::closeAlternative (this=0x7fffffff86d0, beginTerm=-148815331)
    at /home/decoder/LangFuzz/mozilla-central/js/src/yarr/YarrInterpreter.cpp:1603
1603                    ASSERT(m_bodyDisjunction->terms[beginTerm].type == ByteTerm::TypeAlternativeDisjunction);
(gdb) x /4i $pc
=> 0x74c32f <JSC::Yarr::ByteCompiler::closeAlternative(int)+323>:       mov    (%rax),%eax
   0x74c331 <JSC::Yarr::ByteCompiler::closeAlternative(int)+325>:       cmp    $0x4,%eax
   0x74c334 <JSC::Yarr::ByteCompiler::closeAlternative(int)+328>:       setne  %al
   0x74c337 <JSC::Yarr::ByteCompiler::closeAlternative(int)+331>:       test   %al,%al
(gdb) info register rax
rax            0xfffffffe56f3ba40       -7131121088


I assume therefore that this could really be a security problem with the invalid read happening here, so this should be closer investigated in terms of security impact.

Comment 2

[Daniel Veditz [:dveditz]]

causing an OOM at exactly this spot is probably not likely. guessing "moderate".

Comment 3

[Bob Clary [:bc] (inactive)]

This assert happens reliably on Windows 7 32bit for Beta/14, Aurora/15, Nightly/16 at http://www.real-fans.de/Wallpaper/War/

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

$ ./js-dbg-64-ts-darwin-9afe2a1145bd -e "oomAfterAllocations(1076)" -f ~/trees/mozilla-central/js/src/tests/shell.js -f ~/trees/mozilla-central/js/src/tests/js1_7/geniter/shell.js -f ~/trees/mozilla-central/js/src/tests/js1_7/geniter/regress-349331.js
out of memory
out of memory
Assertion failure: [unhandlable oom] OOM in TypeObject::sweep, at /Users/skywalker/trees/mozilla-central/js/src/jscntxt.cpp:1373
Hit MOZ_CRASH() at /Users/skywalker/trees/mozilla-central/js/src/jscntxt.cpp:1374
Segmentation fault: 11

I now hit this assert, so is this still an issue?

(that said, perhaps we'd need to vary the number that we feed into oomAfterAllocations?)

Comment 5

[Christian Holler (:decoder)]

Yes, you probably need to change the allocation number.

The assert you're hitting is unrelated and indicates we're OOMing in the wrong place.

Comment 6

[Hannes Verschore [:h4writer]]

Ran this benchmark with an allocation number between 0-1000. Since I couldn't reproduce with the given allocation count. In most cases it crashes (due to unhandlable oom), which is fine, I think?

But I hit 6 different asserts not related to unhandlable oom (6, 73, 334, 427, 447, 762). I'm gonna create bug reports for them all. First one being bug 992256. I won't post the testcase if not necessary. If I need to I'll make them security bugs, to make sure the testcase isn't made public.

Comment 7

[Hannes Verschore [:h4writer]]

Opened bug 992264 for the "allocation 73" case

Comment 8

[Hannes Verschore [:h4writer]]

Opened bug 992274 for the "allocation 447" case

Comment 9

[Hannes Verschore [:h4writer]]

Bug 990806 is the "allocation 9" case. Though that bug didn't fix all occurrences. I still see it happening on the "allocation 14" case

I run the following command to find it. This also gives other issues...
for i in {1..100}; do echo $i; js -e "oomAfterAllocations($i)" -f ./tests/shell.js -f ./tests/js1_7/geniter/shell.js -f ./tests/js1_7/geniter/regress-349331.js; done

Comment 10

[Hannes Verschore [:h4writer]]

I don't see the original assertion anymore. (It probably has been solved by one of the other yarr fixes) So I guess we can call this closed?

Comment 11

[Chris Peterson [:cpeterson]]

Given Hannes' comment 10, the fixed dependent bugs, and the fact that YARR was replaced by irregexp in Firefox 32 (bug 976446), we can probably close this bug.

Comment 12

[Daniel Veditz [:dveditz]]

We don't need to use the more restrictive component-specific security groups unless a bug is sec-high or sec-critical