Closed Bug 1597203 Opened 8 months ago Closed 7 months ago

Assertion failure: size <= fr.dynamicHeight(), at js/src/wasm/WasmBaselineCompile.cpp:4431

Categories

(Core :: Javascript: WebAssembly, defect, P1)

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla73
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- unaffected
firefox71 --- unaffected
firefox72 --- disabled
firefox73 --- fixed

People

(Reporter: decoder, Assigned: wingo)

Details

(Keywords: assertion, regression, testcase)

Attachments

(2 files)

The attached testcase crashes on mozilla-central revision d6844fe546ad (build with --enable-valgrind --enable-gczeal --enable-tests --enable-fuzzing --enable-debug --enable-address-sanitizer --disable-jemalloc --enable-optimize=-O2, run with --no-threads --wasm-compiler=baseline test.js).

Backtrace:

==29003==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55e803110e22 bp 0x7fff014b8d70 sp 0x7fff014b8d40 T0)
==29003==The signal is caused by a WRITE memory access.
==29003==Hint: address points to the zero page.
    #0 0x55e803110e21 in js::wasm::BaseCompiler::assertStackInvariants() const js/src/wasm/WasmBaselineCompile.cpp:4431:7
    #1 0x55e8030b6e09 in js::wasm::BaseCompiler::emitBody() js/src/wasm/WasmBaselineCompile.cpp:11628:5
    #2 0x55e8031261b3 in js::wasm::BaseCompiler::emitFunction() js/src/wasm/WasmBaselineCompile.cpp:12643:8
    #3 0x55e8031261b3 in js::wasm::BaselineCompileFunctions(js::wasm::ModuleEnvironment const&, js::LifoAlloc&, mozilla::Vector<js::wasm::FuncCompileInput, 8ul, js::SystemAllocPolicy> const&, js::wasm::CompiledCode*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmBaselineCompile.cpp:12808
    #4 0x55e80331470e in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmGenerator.cpp:743:12
    #5 0x55e8033182f4 in js::wasm::ModuleGenerator::locallyCompileCurrentTask() js/src/wasm/WasmGenerator.cpp:776:8
    #6 0x55e8033182f4 in js::wasm::ModuleGenerator::finishFuncDefs() js/src/wasm/WasmGenerator.cpp:914
    #7 0x55e803163bd2 in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) js/src/wasm/WasmCompile.cpp:570:13
    #8 0x55e803162b8b 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*) js/src/wasm/WasmCompile.cpp:593:8
    #9 0x55e80345ae98 in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) js/src/wasm/WasmJS.cpp:1180:7
    [...]
Attached file Testcase

Also seeing this variation:

Assertion failure: size == fr.dynamicHeight(), at js/src/wasm/WasmBaselineCompile.cpp:4421

I assume this is the same bug for now.

Flags: needinfo?(wingo)
Priority: -- → P1

Thanks :)

Assignee: nobody → wingo
Flags: needinfo?(wingo)

Hi, sorry I got a bit sidetracked. Just wanted to let people know I'm still on this.

Minimal reproducer below; run with --no-threads --wasm-compiler=baseline:

new WebAssembly.Instance(new WebAssembly.Module(wasmTextToBinary(`
  (module
    (func (export "main")
      (i32.const 2)
      (i32.const 3)
      (loop (param i32 i32)
        (i32.const 6)
        (i32.const 7)
        (br 0))))`)))

The crash happens right after the br 0 and before the end. Related to bug 1586498.

In this followup fix to bug 1586498, it seems that there are actually no
stack invariants that we can assert.

Looks like not a security bug then?

Flags: needinfo?(choller)

I would like this to remain closed for now, but this is nightly-only and indeed probably js-shell-only, so nothing to be too worried about. Wingo and I will be continuing to discuss what the appropriate invariants are.

Flags: needinfo?(choller)
Group: javascript-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
Flags: in-testsuite+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.