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)
Tracking
()
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)
9.73 KB,
application/octet-stream
|
Details |
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.
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
Julian, maybe you can take a look? Looks like a missing guard in the verifier.
Comment 3•4 years ago
|
||
The MOZ_CRASH() indicates we caught the problem; would there be some way the bad state could get by undetected and then abused?
Assignee | ||
Comment 4•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
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.
Comment 7•4 years ago
|
||
Closing based on comment 6.
Comment 8•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Description
•