Closed Bug 1264998 Opened 8 years ago Closed 8 years ago

Assertion failure: bailoutId < bailoutEntries_, at js/src/jit/IonCode.h:477 involving oomTest

Categories

(Core :: JavaScript Engine, defect)

ARM
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla48
Tracking Status
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox48 --- verified
firefox-esr38 --- wontfix
firefox-esr45 --- wontfix

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, sec-low, testcase, Whiteboard: [jsbugmon:update][adv-main48+])

Attachments

(2 files)

The following testcase crashes on mozilla-central revision 10f66b316457 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-simulator=arm --enable-debug, run with --fuzzing-safe --thread-count=2 --ion-offthread-compile=off):

loadFile(`
setJitCompilerOption("ion.warmup.trigger", 0);
function floor(a, b) {
    return Math.floor((a | 0) / (b | 0)) | 0;
}
assertEq(floor(5, 5), 1);
assertEq(floor(4, 3), 1);
`);
function loadFile(lfVarx)
  oomTest(function() { eval(lfVarx); });



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0846f6d6 in bailoutToSnapshot (bailoutId=1, this=<optimized out>) at js/src/jit/IonCode.h:477
#0  0x0846f6d6 in bailoutToSnapshot (bailoutId=1, this=<optimized out>) at js/src/jit/IonCode.h:477
#1  js::jit::BailoutFrameInfo::BailoutFrameInfo (this=0xffff9fb0, activations=..., bailout=0xf59ffad8) at js/src/jit/arm/Bailouts-arm.cpp:104
#2  0x089a5099 in js::jit::Bailout (sp=sp@entry=0xf59ffad8, bailoutInfo=bailoutInfo@entry=0xf59ffad0) at js/src/jit/Bailouts.cpp:42
#3  0x084f8a82 in js::jit::Simulator::softwareInterrupt (this=0xf7a1c000, instr=0xf7a03784) at js/src/jit/arm/Simulator-arm.cpp:2347
#4  0x084f8d76 in js::jit::Simulator::decodeType7 (this=0xf7a1c000, instr=0xf7a03784) at js/src/jit/arm/Simulator-arm.cpp:3502
#5  0x084f6cb5 in js::jit::Simulator::instructionDecode (this=this@entry=0xf7a1c000, instr=instr@entry=0xf7a03784) at js/src/jit/arm/Simulator-arm.cpp:4424
#6  0x084fab94 in execute<false> (this=0xf7a1c000) at js/src/jit/arm/Simulator-arm.cpp:4479
#7  js::jit::Simulator::callInternal (this=this@entry=0xf7a1c000, entry=entry@entry=0xf7fc89c0 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345t\240\235", <incomplete sequence \345>) at js/src/jit/arm/Simulator-arm.cpp:4567
#8  0x084fb0c0 in js::jit::Simulator::call (this=0xf7a1c000, entry=entry@entry=0xf7fc89c0 "\360O-\351\004\320M\342\020\212-\355\r\200\240\341h\220\235\345t\240\235", <incomplete sequence \345>, argument_count=argument_count@entry=8) at js/src/jit/arm/Simulator-arm.cpp:4650
#9  0x082f3d61 in EnterIon (data=..., cx=0xf7a74020) at js/src/jit/Ion.cpp:2751
#10 js::jit::IonCannon (cx=cx@entry=0xf7a74020, state=...) at js/src/jit/Ion.cpp:2846
#11 0x086fc32f in js::RunScript (cx=cx@entry=0xf7a74020, state=...) at js/src/vm/Interpreter.cpp:406
#12 0x086fc58e in js::InternalCallOrConstruct (cx=0xf7a74020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:498
#13 0x086fc924 in InternalCall (cx=cx@entry=0xf7a74020, args=...) at js/src/vm/Interpreter.cpp:525
#14 0x086fc99f in js::CallFromStack (cx=cx@entry=0xf7a74020, args=...) at js/src/vm/Interpreter.cpp:531
#15 0x0826d2b9 in js::jit::DoCallFallback (cx=cx@entry=0xf7a74020, frame=frame@entry=0xf59ffdd8, stub_=stub_@entry=0xf34b5210, argc=argc@entry=2, vp=vp@entry=0xf59ffd78, res=res@entry=...) at js/src/jit/BaselineIC.cpp:6116
#16 0x084f8b3e in js::jit::Simulator::softwareInterrupt (this=0xf7a1c000, instr=0xf552f2f4) at js/src/jit/arm/Simulator-arm.cpp:2380
[...]
#35 0x0824d986 in EnterBaseline (cx=cx@entry=0xf7a74020, data=...) at js/src/jit/BaselineJIT.cpp:150
#36 0x0826824e in js::jit::EnterBaselineMethod (cx=cx@entry=0xf7a74020, state=...) at js/src/jit/BaselineJIT.cpp:188
#37 0x086fc29b in js::RunScript (cx=cx@entry=0xf7a74020, state=...) at js/src/vm/Interpreter.cpp:416
#38 0x086fc58e in js::InternalCallOrConstruct (cx=0xf7a74020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:498
#39 0x086fc924 in InternalCall (cx=cx@entry=0xf7a74020, args=...) at js/src/vm/Interpreter.cpp:525
#40 0x086fc9d4 in js::Call (cx=0xf7a74020, fval=fval@entry=..., thisv=thisv@entry=..., args=..., rval=rval@entry=...) at js/src/vm/Interpreter.cpp:544
#41 0x0852a800 in JS_CallFunction (cx=cx@entry=0xf7a74020, obj=..., fun=fun@entry=..., args=..., rval=rval@entry=...) at js/src/jsapi.cpp:2876
#42 0x088373e6 in OOMTest (cx=0xf7a74020, argc=1, vp=0xf54260b0) at js/src/builtin/TestingFunctions.cpp:1310
#43 0x08702daa in js::CallJSNative (cx=0xf7a74020, native=0x88370e0 <OOMTest(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235
[...]
#57 main (argc=5, argv=0xffffccb4, envp=0xffffcccc) at js/src/shell/js.cpp:7455
eax	0x0	0
ebx	0x986d31c	159830812
ecx	0xf7e3a88c	-136075124
edx	0x0	0
esi	0x2	2
edi	0xffff9fb0	-24656
ebp	0xffff9f48	4294942536
esp	0xffff9f10	4294942480
eip	0x846f6d6 <js::jit::BailoutFrameInfo::BailoutFrameInfo(js::jit::JitActivationIterator const&, js::jit::BailoutStack*)+486>
=> 0x846f6d6 <js::jit::BailoutFrameInfo::BailoutFrameInfo(js::jit::JitActivationIterator const&, js::jit::BailoutStack*)+486>:	movl   $0x1dd,0x0
   0x846f6e0 <js::jit::BailoutFrameInfo::BailoutFrameInfo(js::jit::JitActivationIterator const&, js::jit::BailoutStack*)+496>:	call   0x8101b70 <abort()>


Since the assertion looks like a range assertion to me, marking as s-s until investigated.
Distributing fuzz bugs at random to make sure they're not lost.
Flags: needinfo?(nicolas.b.pierron)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20151013053056" and the hash "8d9c20c241be7d7b3cfa90a3368a77db42172781".
The "bad" changeset has the timestamp "20151013054956" and the hash "d80f9d6921f8209ef01aa730be9a97ab727704d1".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8d9c20c241be7d7b3cfa90a3368a77db42172781&tochange=d80f9d6921f8209ef01aa730be9a97ab727704d1
Summary: Assertion failure: bailoutId < bailoutEntries_, at js/src/jit/IonCode.h:477 → Assertion failure: bailoutId < bailoutEntries_, at js/src/jit/IonCode.h:477 involving oomTest
Ok, this bug exist since ages, on all platforms which are using a bailout table as a size optimization, i-e ARM and x86.

On the other hand, this OOM bug is quite unlikely to be used as a vector of attack in the wild, because we have a check above which ensure that we have no more than 16 entries of offsets, that are allocated with SystemAllocPolicy.

If this OOM happens, I will expect to have other sources of failures in our Assembler which causes the end of the compilation.

The problem is related to the fact that assignBailoutId optimization tests with error codes.
This patch got reviewed by Hannes in another unrelated bug, as attachment 8742860 [details] [diff].
(I made a typo in the bug number, hopefully this is not critical)
Attachment #8742908 - Flags: review+
Flags: needinfo?(nicolas.b.pierron)
Keywords: sec-low
Comment on attachment 8742908 [details] [diff] [review]
CodeGeneratorShared::assignBailoutId: Properly handle allocation errors.

[Security approval request comment]
> How easily could an exploit be constructed based on the patch?
Hard (= small-OOM in threaded code)

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

The content patch highlight the issue.

> Which older supported branches are affected by this flaw?

All versions since the release of IonMonkey.

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

Bug 670827

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

Should be the same patch.

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

unlikely.
Attachment #8742908 - Flags: sec-approval?
Comment on attachment 8742908 [details] [diff] [review]
CodeGeneratorShared::assignBailoutId: Properly handle allocation errors.

As a sec-low, this doesn't need approval to go into trunk. Just check 'er in!
Attachment #8742908 - Flags: sec-approval?
https://hg.mozilla.org/mozilla-central/rev/c9facac78094
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Group: javascript-core-security → core-security-release
Whiteboard: [jsbugmon:update] → [jsbugmon:update][adv-main48+]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.