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.

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

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. (I made a typo in the bug number, hopefully this is not critical)

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.

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!

(impersonating PulseBot) https://hg.mozilla.org/integration/mozilla-inbound/rev/c9facac78094

JSBugMon: This bug has been automatically verified fixed.