1882481 - [WASM] SEGV during WasmCall in Baseline Compiler

Status: RESOLVED DUPLICATE of bug 1882751

(Core :: JavaScript: WebAssembly, defect)

Description

[P1umer]

Attachment: Reproducible poc

Steps to reproduce:

Git Commit : f909cd37c43c5d9f43b4def8a8064b88b8765533
Build :
ac_add_options --enable-project=js
ac_add_options --disable-optimize
ac_add_options --disable-unified-build
ac_add_options --disable-debug
ac_add_options --disable-jemalloc

Running the POC with --wasm-compiler=baseline

Actual results:

Process 2520284 stopped
* thread #1, name = 'js', stop reason = signal SIGSEGV: invalid address (fault address: 0x3d8774d0095c)
    frame #0: 0x000034d04604a5fa
->  0x34d04604a5fa: movb   %al, (%rcx,%rbx)
    0x34d04604a5fd: testl  %ebx, %ebx
    0x34d04604a5ff: jg     0x34d04604a5f7
    0x34d04604a601: pushq  %rdx
Target 0: (js) stopped.
(lldb) register read/x rbx rcx
     rbx = 0x00000000fffffff4
     rcx = 0x00003d8674d00968
(lldb) bt
* thread #1, name = 'js', stop reason = signal SIGSEGV: invalid address (fault address: 0x3d8774d0095c)
  * frame #0: 0x000034d04604a5fa
    frame #1: 0x000034d04604b7b9
    frame #2: 0x000055555824b459 js`js::wasm::Instance::callExport(this=0x0000555559239230, cx=0x000055555912a0e0, funcIndex=0, args=CallArgs @ 0x000000002619e9c0, level=Spec) at WasmInstance.cpp:3196:10
    frame #3: 0x00005555582c6027 js`WasmCall(cx=0x000055555912a0e0, argc=0, vp=<unavailable>) at WasmJS.cpp:1842:19
    frame #4: 0x0000555556dc56c1 js`js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) [inlined] CallJSNative(cx=0x000055555912a0e0, native=<unavailable>, reason=<unavailable>, args=0x00007fffffffd7c0)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) at Interpreter.cpp:480:13
    frame #5: 0x0000555556dc5567 js`js::InternalCallOrConstruct(cx=0x000055555912a0e0, args=0x00007fffffffd7c0, construct=NO_CONSTRUCT, reason=<unavailable>) at Interpreter.cpp:574:12
    frame #6: 0x0000555556ddc4af js`js::Interpret(JSContext*, js::RunState&) [inlined] InternalCall(cx=0x000055555912a0e0, args=0x00007fffffffd7c0) at Interpreter.cpp:641:10
    frame #7: 0x0000555556ddc4a5 js`js::Interpret(JSContext*, js::RunState&) [inlined] js::CallFromStack(cx=0x000055555912a0e0, args=0x00007fffffffd7c0) at Interpreter.cpp:646:10
    frame #8: 0x0000555556ddc4a5 js`js::Interpret(cx=0x000055555912a0e0, state=0x00007fffffffd8f0) at Interpreter.cpp:3061:16
    frame #9: 0x0000555556dc4b50 js`js::RunScript(JSContext*, js::RunState&) [inlined] MaybeEnterInterpreterTrampoline(cx=0x000055555912a0e0, state=0x00007fffffffd8f0) at Interpreter.cpp:394:10
    frame #10: 0x0000555556dc4b25 js`js::RunScript(cx=0x000055555912a0e0, state=0x00007fffffffd8f0) at Interpreter.cpp:452:13
    frame #11: 0x0000555556dc7ca0 js`js::ExecuteKernel(cx=<unavailable>, script=<unavailable>, envChainArg=<unavailable>, evalInFrame=(ptr_ = 0), result=<unavailable>) at Interpreter.cpp:839:13
    frame #12: 0x0000555556dc7ecc js`js::Execute(cx=<unavailable>, script=<unavailable>, envChain=<unavailable>, rval=<unavailable>) at Interpreter.cpp:871:10 [artificial]
    frame #13: 0x00005555570d354d js`ExecuteScript(cx=<unavailable>, envChain=<unavailable>, script=<unavailable>, rval=<unavailable>) at CompilationAndEvaluation.cpp:494:10 [artificial]
    frame #14: 0x00005555570d36df js`JS_ExecuteScript(cx=0x000055555912a0e0, scriptArg=JS::HandleScript @ scalar) at CompilationAndEvaluation.cpp:518:10
    frame #15: 0x0000555556d10b98 js`RunFile(cx=0x000055555912a0e0, filename="/tmp/crash.js", file=0x0000555559252f40, compileMethod=DontInflate, compileOnly=false, fullParse=false) at js.cpp:1200:10
    frame #16: 0x0000555556d10281 js`Process(cx=0x000055555912a0e0, filename="/tmp/crash.js", forceTTY=false, kind=FileScript) at js.cpp:1780:14
    frame #17: 0x0000555556ccbcb7 js`Shell(JSContext*, js::cli::OptionParser*) at js.cpp:10991:10
    frame #18: 0x0000555556ccbc15 js`Shell(cx=0x000055555912a0e0, op=0x00007fffffffdef8) at js.cpp:11250:12
    frame #19: 0x0000555556cc1391 js`main(argc=<unavailable>, argv=<unavailable>) at js.cpp:11758:12
    frame #20: 0x00007ffff7a48083 libc.so.6`__libc_start_main + 243
    frame #21: 0x0000555556ca3889 js`_start + 41

Comment 1

[Yury Delendik (:yury)]

Reduced test case:

var wasm_code = wasmTextToBinary(`(module
  (type $t0 (array (mut i8)))
  (func (export "main")       
    (drop
      (array.new $t0 (i32.const 0) (i32.const 0)))
    (drop
      (array.new $t0 (i32.const 0) (i32.const -11)))
  )
)`);  
var wasm_module = new WebAssembly.Module(wasm_code);
var wasm_instance = new WebAssembly.Instance(wasm_module);
wasm_instance.exports.main();

Observation: it does not fail without first (drop). The length is negative for array.new (cc'ing Ben)

Comment 2

[Yury Delendik (:yury)]

Can you further triage this bug based on information you have about other similar array.new bugs?

Comment 4

[P1umer]

Hello, I had submitted my report earlier and I'm a bit puzzled as to why this bug has been marked as a duplicate of one reported later.

Comment 5

[Ryan Hunt [:rhunt]]

(In reply to P1umer from comment #4)

Hello, I had submitted my report earlier and I'm a bit puzzled as to why this bug has been marked as a duplicate of one reported later.

This is only because we triaged and attached a fix to that one first. It's easier to keep all development in one central place. I don't believe it affects how the security team evaluates credit for discovering issues. We cc'ed you on the new bug so you should be able to follow the development there.

Comment 6

[P1umer]

(In reply to Ryan Hunt [:rhunt] from comment #5)

(In reply to P1umer from comment #4)

Hello, I had submitted my report earlier and I'm a bit puzzled as to why this bug has been marked as a duplicate of one reported later.

This is only because we triaged and attached a fix to that one first. It's easier to keep all development in one central place. I don't believe it affects how the security team evaluates credit for discovering issues. We cc'ed you on the new bug so you should be able to follow the development there.

Thanks for the quick reply and for clearing that up.

Comment 7

[Daniel Veditz [:dveditz]]

I don't believe it affects how the security team evaluates credit for discovering issues.

It does not. In this case they were filed 26hrs apart which is within our collision window, so we will credit both of you.

Comment 8

[Daniel Veditz [:dveditz]]

We are awarding a bounty for this bug, split with the reporter of colliding bug 1882751

We're assuming you wanted to submit this to our bug bounty program since you submitted bug 1880719. Please make sure to set the sec-bounty flag to '?' or use the bug bounty form when you submit these or we may not notice.