Closed Bug 1282502 Opened 3 years ago Closed 3 years ago

Crash [@ js::frontend::BytecodeEmitter::emitUnaliasedVarOp] or Assertion failure: num <= (65535), at jsscript.h:451


(Core :: JavaScript Engine, defect, critical)

Not set



Tracking Status
firefox47 --- wontfix
firefox48 + verified
firefox49 + verified
firefox-esr45 48+ fixed
firefox50 + verified


(Reporter: decoder, Assigned: jonco)


(Blocks 1 open bug)


(6 keywords, Whiteboard: [jsbugmon:update][adv-main48+][adv-esr45.3+])

Crash Data


(2 files)

The following testcase crashes on mozilla-central revision 0e073f5ca38a (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu, run with --fuzzing-safe):

try {
    for (var i = 0; i < 20000; i++) {
        r &= f();
} catch (exc) {}
let s = '  {';
let max = 65536;
for (let target  = 0; i < max; i++)
  s += "let ns" + i + " = "+ i +";\\n";
s += "};";


 received signal SIGSEGV, Segmentation fault.
js::frontend::BytecodeEmitter::emitUnaliasedVarOp (op=JSOP_INITLEXICAL, checkLexical=js::DontCheckLexical, checkLexical=js::DontCheckLexical, slot=65535, op=JSOP_INITLEXICAL, this=0xffffbe50) at js/src/frontend/BytecodeEmitter.cpp:1201
#0  js::frontend::BytecodeEmitter::emitUnaliasedVarOp (op=JSOP_INITLEXICAL, checkLexical=js::DontCheckLexical, checkLexical=js::DontCheckLexical, slot=65535, op=JSOP_INITLEXICAL, this=0xffffbe50) at js/src/frontend/BytecodeEmitter.cpp:1201
#1  js::frontend::BytecodeEmitter::initializeBlockScopedLocalsFromStack (this=0xffffbe50, blockScope=...) at js/src/frontend/BytecodeEmitter.cpp:3158
#2  0x08624b3d in js::frontend::BytecodeEmitter::enterBlockScope (this=0xffffbe50, stmtInfo=0xffffb128, objbox=0xf79c3218, initialValueOp=JSOP_UNINITIALIZED, alreadyPushed=0) at js/src/frontend/BytecodeEmitter.cpp:3191
#3  0x0862a504 in js::frontend::BytecodeEmitter::emitLexicalScope (this=0xffffbe50, pn=0xf79c3228) at js/src/frontend/BytecodeEmitter.cpp:5555
#4  0x08624eba in js::frontend::BytecodeEmitter::emitTree (this=0xffffbe50, pn=0xf79c3228, emitLineNote=js::frontend::BytecodeEmitter::EMIT_LINENOTE) at js/src/frontend/BytecodeEmitter.cpp:8968
#5  0x0862bad3 in js::frontend::BytecodeEmitter::emitStatementList (this=0xffffbe50, pn=0xf79c31c8) at js/src/frontend/BytecodeEmitter.cpp:7194
#6  0x08625202 in js::frontend::BytecodeEmitter::emitTree (this=0xffffbe50, pn=0xf79c31c8, emitLineNote=js::frontend::BytecodeEmitter::EMIT_LINENOTE) at js/src/frontend/BytecodeEmitter.cpp:8813
#7  0x0862a520 in js::frontend::BytecodeEmitter::emitLexicalScope (this=0xffffbe50, pn=0xf79c31a0) at js/src/frontend/BytecodeEmitter.cpp:5568
#8  0x08624eba in js::frontend::BytecodeEmitter::emitTree (this=0xffffbe50, pn=0xf79c31a0, emitLineNote=js::frontend::BytecodeEmitter::EMIT_LINENOTE) at js/src/frontend/BytecodeEmitter.cpp:8968
#9  0x086256cb in BytecodeCompiler::prepareAndEmitTree (this=0xffffb554, ppn=0xffffb334) at js/src/frontend/BytecodeCompiler.cpp:356
#10 0x08625cab in BytecodeCompiler::compileScript (this=0xffffb554, scopeChain=..., evalCaller=...) at js/src/frontend/BytecodeCompiler.cpp:539
#11 0x08625e2f in js::frontend::CompileScript (cx=0xf7977140, alloc=0xf7928198, scopeChain=..., enclosingStaticScope=..., evalCaller=..., options=..., srcBuf=..., source_=0xf3cb2180, extraSct=0x0, sourceObjectOut=0x0) at js/src/frontend/BytecodeCompiler.cpp:742
#12 0x0846aa54 in EvalKernel (cx=cx@entry=0xf7977140, v=..., v@entry=..., evalType=evalType@entry=DIRECT_EVAL, caller=..., scopeobj=..., pc=0xf4b07016 "{", vp=...) at js/src/builtin/Eval.cpp:321
#13 0x0846addc in js::DirectEval (cx=0xf7977140, v=..., vp=...) at js/src/builtin/Eval.cpp:451
#14 0x0818ada5 in js::jit::DoCallFallback (cx=0xf7977140, frame=0xffffc5d8, stub_=0xf798b3b8, argc=1, vp=0xffffc590, res=...) at js/src/jit/BaselineIC.cpp:5955
#15 0xf7be8181 in ?? ()
#16 0xf798b3b8 in ?? ()
#17 0xf7be292e in ?? ()
#18 0x0815fb83 in EnterBaseline (cx=0xf798b3b8, cx@entry=0xf7977140, data=...) at js/src/jit/BaselineJIT.cpp:156
#19 0x08162b1c in js::jit::EnterBaselineAtBranch (cx=0xf7977140, fp=0xf4b1c088, pc=0xf4b06fdd "ず") at js/src/jit/BaselineJIT.cpp:262
#20 0x084ed99f in Interpret (cx=0xf7977140, state=...) at js/src/vm/Interpreter.cpp:1877
#21 0x084edd7a in js::RunScript (cx=0xf7977140, state=...) at js/src/vm/Interpreter.cpp:398
#22 0x084efe8d in js::ExecuteKernel (result=0xf4b1c060, evalInFrame=..., newTargetValue=..., scopeChainArg=..., script=..., cx=0xf7977140) at js/src/vm/Interpreter.cpp:676
#23 js::Execute (cx=0xf7977140, script=..., scopeChainArg=..., rval=0xf4b1c060) at js/src/vm/Interpreter.cpp:709
#24 0x0837bab9 in ExecuteScript (cx=cx@entry=0xf7977140, scope=scope@entry=..., script=script@entry=..., rval=0xf4b1c060) at js/src/jsapi.cpp:4364
#25 0x08381e76 in JS_ExecuteScript (cx=0xf7977140, scriptArg=..., rval=...) at js/src/jsapi.cpp:4390
#26 0x08083a61 in Evaluate (cx=0xf7977140, argc=1, vp=0xf4b1c060) at js/src/shell/js.cpp:1480
#27 0x084ee1d5 in js::CallJSNative (args=..., native=<optimized out>, cx=0xf7977140) at js/src/jscntxtinlines.h:235
#40 Shell (envp=<optimized out>, op=0xffffd7a0, cx=<optimized out>) at js/src/shell/js.cpp:7050
#41 main (argc=3, argv=0xffffd8e4, envp=0xffffd8f4) at js/src/shell/js.cpp:7432
eax	0xffffbf24	-16604
ebx	0xffff	65535
ecx	0xf3cb1220	-204795360
edx	0xf4e571f0	-186289680
esi	0x898fff4	144244724
edi	0xffffbe50	-16816
ebp	0x10001	65537
esp	0xffffb04c	4294946892
eip	0x8620523 <js::frontend::BytecodeEmitter::initializeBlockScopedLocalsFromStack(JS::Handle<js::StaticBlockScope*>)+227>
=> 0x8620523 <js::frontend::BytecodeEmitter::initializeBlockScopedLocalsFromStack(JS::Handle<js::StaticBlockScope*>)+227>:	mov    (%eax,%ebx,4),%ebx
   0x8620526 <js::frontend::BytecodeEmitter::initializeBlockScopedLocalsFromStack(JS::Handle<js::StaticBlockScope*>)+230>:	pushl  0x20(%esp)

Looks like an out of bounds access to me, marking s-s and sec-high at least.
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160413060947" and the hash "98048beb73c9f14d7bce903e97df5ec5a660e813".
The "bad" changeset has the timestamp "20160413061245" and the hash "009ffacae51adc5d234a7fdde48c82970de097f8".

Likely regression window:
Flags: needinfo?(jcoppeard)
Add a check to see if the block scope depth is greater than that which can be represented in the Bindings structure.

I don't think this is related to my previous patch, although that does trigger a debug assertion in this case.
Assignee: nobody → jcoppeard
Flags: needinfo?(jcoppeard)
Attachment #8765829 - Flags: review?(shu)
Attachment #8765829 - Flags: review?(shu) → review+
Comment on attachment 8765829 [details] [diff] [review]

[Security approval request comment]
How easily could an exploit be constructed based on the patch?  I'm going to say 'moderate' because it's reasonably obvious that this adds a bounds check, although I'm not exactly sure how I would use this to create an exploit.

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?  I tested and this reproduces on ESR 45.

If not all supported branches, which bug introduced the flaw?  I think everything is affected.

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

How likely is this patch to cause regressions; how much testing does it need?  The patch is simple and is unlikely to cause regressions.
Attachment #8765829 - Flags: sec-approval?
sec-approval+ for trunk. Can we get Aurora, Beta, and ESR45 patches made and nominated please?
Attachment #8765829 - Flags: sec-approval? → sec-approval+
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
JSBugMon: This bug has been automatically verified fixed.
Group: javascript-core-security → core-security-release
Comment on attachment 8765829 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: Bug 962599.
[User impact if declined]: Possible crash / security vulnerability.
[Describe test coverage new/current, TreeHerder]: On m-c since 7th July.
[Risks and why]: Low
[String/UUID change made/needed]: None
Attachment #8765829 - Flags: approval-mozilla-beta?
Attachment #8765829 - Flags: approval-mozilla-aurora?
Attached patch bug1282502-esr45Splinter Review
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-high bug
User impact if declined: Possible crash / security vulnerability
Fix Landed on Version: 50
Risk to taking this patch (and alternatives if risky): Low
String or UUID changes made by this patch: None

See for more info.
Attachment #8770216 - Flags: review+
Attachment #8770216 - Flags: approval-mozilla-esr45?
Comment on attachment 8770216 [details] [diff] [review]

Sec-high, should fix some crashes, OK to uplift to ESR
Attachment #8770216 - Flags: approval-mozilla-esr45? → approval-mozilla-esr45+
Comment on attachment 8765829 [details] [diff] [review]

Crash fix, sec-high. OK to uplift to aurora and beta. This may make it into today's beta 8 build but if not it will be in the beta 9 build on Monday.
Attachment #8765829 - Flags: approval-mozilla-beta?
Attachment #8765829 - Flags: approval-mozilla-beta+
Attachment #8765829 - Flags: approval-mozilla-aurora?
Attachment #8765829 - Flags: approval-mozilla-aurora+
JSBugMon: This bug has been automatically verified fixed on Fx48
JSBugMon: This bug has been automatically verified fixed on Fx49
Whiteboard: [jsbugmon:update] → [jsbugmon:update][adv-main48+][adv-esr45.3+]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.