jewelzms added the cranelift label to Issue #10072.
jewelzms added the bug label to Issue #10072.
jewelzms opened issue #10072:
Due to the wasm bytecode, segmentation fault occurred in wasmtime.
Memory corruption: The wasm virtual machine's memory is accidentally changed or overwritten, causing unpredictable behavior and crashing.
Webassembly program code in wat format
The wasm program is generated by compiling C++ code with emscripten=3.0.0,
call callEvm
The approximate stack information is as follows:
(gdb) bt #0 0x00007f2b1838c8c0 in ?? () #1 0x000000000bf3b5a0 in ?? () #2 0x00000000ffffffff in ?? () #3 0x00007f2af928e4e0 in ?? () #4 0x00007f2b18380440 in ?? () #5 0x00000000005009cc in alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::do_reserve_and_handle::hbed38fde89062790 () #6 0x000000000b7d0640 in ?? () #7 0x000000000bf3b5a0 in ?? () #8 0x0000000000000002 in ?? () #9 0x00000000005009c0 in alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::do_reserve_and_handle::hbed38fde89062790 () #10 0x0000000000500a88 in alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::do_reserve_and_handle::h74d92f7758c8d10c () #11 0x00007f2b1838e523 in ?? () #12 0x0000000000000001 in ?? () #13 0x00000000010ca458 in wasmtime_setjmp () #14 0x0000000000be58d8 in wasmtime_runtime::traphandlers::catch_traps::hb97e20ad6ff5e857 () #15 0x00000000012ceab4 in wasmtime::func::invoke_wasm_and_catch_traps::h584ffbfdcda01e22 () #16 0x00000000012d1bea in wasmtime::func::Func::call_impl::h84b60e01c03de7c5 () #17 0x0000000000bea454 in wasmtime_func_call ()
Versions and Environment
Cranelift version or commit: all versions
Operating system: Linuxmint 23
Architecture: x86_64
Extra Info
Defined custom environment interfaces.
- uint32_t GetParameters(uint8_t** data_ptr);
- void CalcHash(const uint8_t* data, uint32_t data_size, array32 hash);
- int Call(const uint8_t* address, uint32_t address_size, const uint8_t* data, uint32_t data_size, uint8_t** output_ptr, uint32_t* output_length);
- void Revert(const uint8_t* reason, uint32_t size);
alexcrichton commented on issue #10072:
If you believe you have found a security issue in Wasmtime, such as segfault as you mention here in the runtime, please follow our guidelines for a security report. As-is this report presents a text-level wasm module with no reproduction steps. Given that it's not clear what the "custom environment interfaces" are doing or how to trigger this crash.
You have attached a gdb backtrace but can you provide more info as to what it's doing? It looks corrupted for example as
0x0000000000000002
probably isn't a return pointer. How did you trigger this crash?I'll also note that in the backtrace there are symbols such as
wasmtime_setjmp
. Can you confirm what version of Wasmtime you're using? For quite awhile now wasmtime has put its own version number in this symbol name which looks like you're using a pretty old version of Wasmtime which may have since received a bug fix. You claim that this issue affects "all versions" of Wasmtime but can you expand why you think that's the case?I'll note though that if you believe you have found a security issue please follow our guidelines for a security report and we'll continue the conversation there. The questions I'm presenting here are the same questions we'll ask you on the security report, but in such a situation it's best to conduct such communication in a non-public place initially.
pchickey closed issue #10072:
Due to the wasm bytecode, segmentation fault occurred in wasmtime.
Memory corruption: The wasm virtual machine's memory is accidentally changed or overwritten, causing unpredictable behavior and crashing.
Webassembly program code in wat format
The wasm program is generated by compiling C++ code with emscripten=3.0.0,
call callEvm
The approximate stack information is as follows:
(gdb) bt #0 0x00007f2b1838c8c0 in ?? () #1 0x000000000bf3b5a0 in ?? () #2 0x00000000ffffffff in ?? () #3 0x00007f2af928e4e0 in ?? () #4 0x00007f2b18380440 in ?? () #5 0x00000000005009cc in alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::do_reserve_and_handle::hbed38fde89062790 () #6 0x000000000b7d0640 in ?? () #7 0x000000000bf3b5a0 in ?? () #8 0x0000000000000002 in ?? () #9 0x00000000005009c0 in alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::do_reserve_and_handle::hbed38fde89062790 () #10 0x0000000000500a88 in alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::do_reserve_and_handle::h74d92f7758c8d10c () #11 0x00007f2b1838e523 in ?? () #12 0x0000000000000001 in ?? () #13 0x00000000010ca458 in wasmtime_setjmp () #14 0x0000000000be58d8 in wasmtime_runtime::traphandlers::catch_traps::hb97e20ad6ff5e857 () #15 0x00000000012ceab4 in wasmtime::func::invoke_wasm_and_catch_traps::h584ffbfdcda01e22 () #16 0x00000000012d1bea in wasmtime::func::Func::call_impl::h84b60e01c03de7c5 () #17 0x0000000000bea454 in wasmtime_func_call ()
Versions and Environment
Cranelift version or commit: all versions
Operating system: Linuxmint 23
Architecture: x86_64
Extra Info
Defined custom environment interfaces.
- uint32_t GetParameters(uint8_t** data_ptr);
- void CalcHash(const uint8_t* data, uint32_t data_size, array32 hash);
- int Call(const uint8_t* address, uint32_t address_size, const uint8_t* data, uint32_t data_size, uint8_t** output_ptr, uint32_t* output_length);
- void Revert(const uint8_t* reason, uint32_t size);
pchickey commented on issue #10072:
It’s very generous of Alex to use his valuable time to list the many deficiencies in this report, but I think we can close this as AI generated spam and not waste any more time.
Last updated: Jan 24 2025 at 00:11 UTC