Closed Bug 1629496 Opened 4 years ago Closed 4 years ago

Crash [@ js::jit::MBasicBlock::New] with uninitialized memory


(Core :: JavaScript: WebAssembly, defect)

Not set



Tracking Status
firefox-esr68 --- unaffected
firefox75 --- unaffected
firefox76 --- unaffected
firefox77 --- verified


(Reporter: decoder, Assigned: wingo)




(Keywords: crash, regression, testcase, Whiteboard: [bugmon:update,bisect])

Crash Data


(2 files)

The following testcase crashes on mozilla-central revision 20200410-82d84da94d8d (debug build, run with --fuzzing-safe --no-threads --ion-warmup-threshold=1 --baseline-warmup-threshold=0 --disable-oom-functions test.js):

See attachment.


received signal SIGSEGV, Segmentation fault.
0x00005555567453e8 in js::jit::MBasicBlock::New(js::jit::MIRGraph&, js::jit::CompileInfo const&, js::jit::MBasicBlock*, js::jit::MBasicBlock::Kind) ()
#0  0x00005555567453e8 in js::jit::MBasicBlock::New(js::jit::MIRGraph&, js::jit::CompileInfo const&, js::jit::MBasicBlock*, js::jit::MBasicBlock::Kind) ()
#1  0x0000555556891492 in EmitLoop((anonymous namespace)::FunctionCompiler&) ()
#2  0x000055555688943d in EmitBodyExprs((anonymous namespace)::FunctionCompiler&) ()
#3  0x0000555556887a41 in js::wasm::IonCompileFunctions(js::wasm::ModuleEnvironment const&, js::LifoAlloc&, mozilla::Vector<js::wasm::FuncCompileInput, 8ul, js::SystemAllocPolicy> const&, js::wasm::CompiledCode*, mozilla::UniquePtr<char [], JS::FreePolicy>*) ()
#4  0x0000555556872f4d in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) ()
#5  0x0000555556873d47 in js::wasm::ModuleGenerator::finishFuncDefs() ()
#6  0x00005555567fff0e in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) ()
#7  0x00005555567ffaa9 in js::wasm::CompileBuffer(js::wasm::CompileArgs const&, js::wasm::ShareableBytes const&, mozilla::UniquePtr<char [], JS::FreePolicy>*, mozilla::Vector<mozilla::UniquePtr<char [], JS::FreePolicy>, 0ul, js::SystemAllocPolicy>*, JS::OptimizedEncodingListener*) ()
#8  0x00005555568d6226 in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) ()
#9  0x00005555559067c2 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) ()
#10 0x000055555591a989 in CallJSNativeConstructor(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) ()
#11 0x0000555555907b8c in InternalConstruct(JSContext*, js::AnyConstructArgs const&) ()
#12 0x00005555563c865f in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) ()
#13 0x000032bc284860d3 in ?? ()
#41 0x0000000000000000 in ?? ()
rax	0x7ffff58c21a8	140737312989608
rbx	0x7ffff58c2040	140737312989248
rcx	0x0	0
rdx	0xfa80	64128
rsi	0xcececececececece	-3544668469065756978
rdi	0x7fffffff6eb0	140737488318128
rbp	0x7fffffff6b40	140737488317248
rsp	0x7fffffff6ae0	140737488317152
r8	0x7f	127
r9	0x0	0
r10	0x7ffff5800000	140737312194560
r11	0x10	16
r12	0x7ffff58c2490	140737312990352
r13	0x0	0
r14	0x7fffffff6d80	140737488317824
r15	0x7ffff58c2308	140737312989960
rip	0x5555567453e8 <js::jit::MBasicBlock::New(js::jit::MIRGraph&, js::jit::CompileInfo const&, js::jit::MBasicBlock*, js::jit::MBasicBlock::Kind)+728>
=> 0x5555567453e8 <_ZN2js3jit11MBasicBlock3NewERNS0_8MIRGraphERKNS0_11CompileInfoEPS1_NS1_4KindE+728>:	movzbl 0x30(%rsi),%eax
   0x5555567453ec <_ZN2js3jit11MBasicBlock3NewERNS0_8MIRGraphERKNS0_11CompileInfoEPS1_NS1_4KindE+732>:	cmp    $0x10,%al

Marking s-s because the crash pattern indicates a use of uninitialized memory.

Attached file Testcase

Single-file reproducer:

let bytes = wasmTextToBinary(`
    (func $f (param) (result i32 i32)
      (local i32)

new WebAssembly.Instance(new WebAssembly.Module(bytes));

I guess there is something that defines the result as a single phi instead of multiple phis. Will fix tomorrow. What an embarrassing bug :/

Ion functions with locals and stack results were inadvertantly skipping
a local, because they were considering the stack results pointer
argument as counting towards locals.

Assignee: nobody → wingo

This bug has been present in nightly since was landed.

Comment on attachment 9140326 [details]
Bug 1629496 - Correctly init wasm locals for functions with stack results

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: Pretty easily I would think
  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
  • Which older supported branches are affected by this flaw?: None
  • If not all supported branches, which bug introduced the flaw?: Bug 1625927
  • Do you have backports for the affected branches?: Yes
  • If not, how different, hard to create, and risky will they be?:
  • How likely is this patch to cause regressions; how much testing does it need?: Does not regress
Attachment #9140326 - Flags: sec-approval?

Note, code is nightly-only, it's not even available behind a flag on non-nightly.

Attachment #9140095 - Attachment mime type: application/octet-stream → text/plain
Attachment #9140095 - Attachment filename: test.js →
Attachment #9140095 - Attachment mime type: text/plain → application/octet-stream
Has Regression Range: --- → yes

Comment on attachment 9140326 [details]
Bug 1629496 - Correctly init wasm locals for functions with stack results

sec-approval+, though you don't need it for nightly-only regressions regardless of severity.

Attachment #9140326 - Flags: sec-approval? → sec-approval+
Group: javascript-core-security → core-security-release
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Keywords: bugmon
Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20200423145559-03626342f6e6.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.