Closed Bug 1673555 Opened 4 years ago Closed 4 years ago

Hit MOZ_CRASH(assertion failed: x < ::cranelift_entity::__core::u32::MAX) at third_party/rust/cranelift-wasm/src/translation_utils.rs:56

Categories

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

ARM64
Linux
defect

Tracking

()

RESOLVED FIXED
85 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- fixed

People

(Reporter: decoder, Assigned: jseward)

References

Details

(5 keywords, Whiteboard: [sec-survey][post-critsmash-triage][adv-main85+r])

Attachments

(1 file)

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

Backtrace:

==10825==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0xaaaab1068278 bp 0xffffe2f149d0 sp 0xffffe2f149d0 T10825)
==10825==The signal is caused by a WRITE memory access.
==10825==Hint: address points to the zero page.
    #0 0xaaaab1068278 in MOZ_Crash(char const*, int, char const*) dist/include/mozilla/Assertions.h:254:3
    #1 0xaaaab1068278 in RustMozCrash mozglue/static/rust/wrappers.cpp:17:3
    #2 0xaaaab1067f18 in mozglue_static::panic_hook::hca87c2370f044745 mozglue/static/rust/lib.rs:89:9
    #3 0xaaaab1067448 in core::ops::function::Fn::call::he723c3abb2e3c6ec /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/ops/function.rs:70:5
    #4 0xaaaab1726334 in std::panicking::rust_panic_with_hook::h3365a52210317c21 /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:573:17
    #5 0xaaaab129bef0 in std::panicking::begin_panic::_$u7b$$u7b$closure$u7d$$u7d$::h119850248dd024b3 /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:498:9
    #6 0xaaaab129beb0 in std::sys_common::backtrace::__rust_end_short_backtrace::hcd91903ba6d8983c /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/sys_common/backtrace.rs:153:18
    #7 0xaaaab129b0d4 in std::panicking::begin_panic::h6005149cb2bea787 /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:497:12
    #8 0xaaaab128da00 in cranelift_wasm::translation_utils::MemoryIndex::from_u32::he288b544e82480bf third_party/rust/cranelift-entity/src/lib.rs:98:17
    #9 0xaaaab10f9b6c in cranelift_wasm::state::func_state::FuncTranslationState::get_heap::hb902bf055cf7afd4 third_party/rust/cranelift-wasm/src/state/func_state.rs:469:21
    #10 0xaaaab10f6b88 in cranelift_wasm::code_translator::finalise_atomic_mem_addr::hba11e8ccaa412e50 third_party/rust/cranelift-wasm/src/code_translator.rs:2079:16
    #11 0xaaaab10f68cc in cranelift_wasm::code_translator::translate_atomic_store::h170c30966b9d609f third_party/rust/cranelift-wasm/src/code_translator.rs:2269:9
    #12 0xaaaab10ecc3c in cranelift_wasm::code_translator::translate_operator::hd188ac7149999db4 third_party/rust/cranelift-wasm/src/code_translator.rs:1075:13
    #13 0xaaaab10ea610 in cranelift_wasm::func_translator::parse_function_body::h48678779db95366f third_party/rust/cranelift-wasm/src/func_translator.rs:234:9
    #14 0xaaaab10e9ac0 in cranelift_wasm::func_translator::FuncTranslator::translate_body::hfdf50c6efd864ec1 third_party/rust/cranelift-wasm/src/func_translator.rs:112:9
    #15 0xaaaab10e9d78 in cranelift_wasm::func_translator::FuncTranslator::translate::hdf299cb3028b4bc7 third_party/rust/cranelift-wasm/src/func_translator.rs:64:9
    #16 0xaaaab10cc838 in baldrdash::compile::BatchCompiler::translate_wasm::he42acc24020e347e js/src/wasm/cranelift/src/compile.rs:179:9
    #17 0xaaaab10cb1a8 in cranelift_compile_function js/src/wasm/cranelift/src/lib.rs:230:21
    #18 0xaaaab0b2a5e4 in js::wasm::CraneliftCompileFunctions(js::wasm::ModuleEnvironment const&, js::wasm::CompilerEnvironment const&, js::LifoAlloc&, mozilla::Vector<js::wasm::FuncCompileInput, 8ul, js::SystemAllocPolicy> const&, js::wasm::CompiledCode*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmCraneliftCompile.cpp:537:10
    #19 0xaaaab0b4c3c0 in ExecuteCompileTask(js::wasm::CompileTask*, mozilla::UniquePtr<char [], JS::FreePolicy>*) js/src/wasm/WasmGenerator.cpp:750:16
    #20 0xaaaab0b4e2e8 in js::wasm::ModuleGenerator::locallyCompileCurrentTask() js/src/wasm/WasmGenerator.cpp:822:8
    #21 0xaaaab0b4e2e8 in js::wasm::ModuleGenerator::finishFuncDefs() js/src/wasm/WasmGenerator.cpp:960:24
    #22 0xaaaab0a87dac in bool DecodeCodeSection<js::wasm::Decoder>(js::wasm::ModuleEnvironment const&, js::wasm::Decoder&, js::wasm::ModuleGenerator&) js/src/wasm/WasmCompile.cpp:569:13
    #23 0xaaaab0a876c4 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*, JSTelemetrySender) js/src/wasm/WasmCompile.cpp:592:8
    #24 0xaaaab0ba6440 in js::WasmModuleObject::construct(JSContext*, unsigned int, JS::Value*) js/src/wasm/WasmJS.cpp:1597:25
    #25 0xaaaaafb95c40 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) js/src/vm/Interpreter.cpp:506:13
    [...]

Marking s-s because aarch64 cranelift is enabled by default as far as I remember.

Attached file Testcase

Julian, maybe you can take a look? Looks like a missing guard in the verifier.

Flags: needinfo?(jseward)

The MOZ_CRASH() indicates we caught the problem; would there be some way the bad state could get by undetected and then abused?

Yeah, it looks a lot like "atomic insns used, but no linear memory, and the
verifier didn't catch it". I'll investigate.

The MOZ_CRASH() is only arrived at as a result of a failing Rust debug_assert.
So we wouldn't have caught this failure (at this stage, at least) in a release build.
Could it be abused? I don't know.

Flags: needinfo?(jseward)
Assignee: nobody → jseward
Severity: -- → S2
Status: NEW → ASSIGNED
Priority: -- → P1
Keywords: sec-high

Actually it is "atomic insns used, specifying memory number 0xFFFF'FFFF,
and no checking for multiple memories in the verifier."

The fix seems simple enough; it's a 1-liner. Unfortunately it is in the
wasmparser crate, which is a second-level dependency for us, so it's
going to take a bit of adminstrative work to make it available in our tree.

This bug, and bug 1678582, will be fixed once bug 1680509 lands. 1680509 is ostensibly just a revendor to our private wasmtime/wasm-tools/regalloc.rs repos, and contains no test cases, so we'll have to land this bug's test case separately when the time is right.

Closing based on comment 6.

Group: javascript-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch
Depends on: 1680509

As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.

Please visit this google form to reply.

Flags: needinfo?(jseward)
Whiteboard: [sec-survey]
Flags: qe-verify-
Whiteboard: [sec-survey] → [sec-survey][post-critsmash-triage]
Whiteboard: [sec-survey][post-critsmash-triage] → [sec-survey][post-critsmash-triage][adv-main85+r]
Flags: needinfo?(jseward)
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: