Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[crash] assertion failed or unimplemented panic when table type is not anyref #1601

Closed
pventuzelo opened this issue Apr 25, 2020 · 2 comments · Fixed by #1626
Closed

[crash] assertion failed or unimplemented panic when table type is not anyref #1601

pventuzelo opened this issue Apr 25, 2020 · 2 comments · Fixed by #1626
Labels
bug Incorrect behavior in the current implementation that needs fixing

Comments

@pventuzelo
Copy link
Contributor

Description

Hey guys,

During fuzzing wasmtime with cranelift backend and almost all features enabled in the config, I trigger those bugs:

If you process the crashing wasm module using wasmtime = "0.15" crate, you will trigger a reachable assertion (CWE-617):

$ ./workspace/debug/target/debug/debug_wasmtime_all_cranelift assert_wasmtime_table_type_anyref.wasm 
Start debugging of wasmtime_all_cranelift
file_to_process: "assert_wasmtime_table_type_anyref.wasm"
thread 'main' panicked at 'assertion failed: tt.element_type == wasmparser::Type::AnyFunc ||
    tt.element_type == wasmparser::Type::AnyRef', /home/scop/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmtime-0.15.0/src/module.rs:56:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

If you process the wasm module using wasmtime cli, you will trigger an unimplemented panic:

$ wasmtime --enable-all assert_wasmtime_table_type_anyref.wasm
thread 'main' panicked at 'not implemented: tables of types other than anyfunc (f32)', crates/runtime/src/table.rs:25:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Steps to reproduce the issue

Download the crashing file: assert_wasmtime_table_type_anyref.zip

Testing piece of code:

    use wasmtime::{Config, Engine, Module, Store, Strategy};

    // read data from provided file
    let data = read_contents_from_path(&args[1]).expect("cannot read file content");
    
    let mut config = Config::new();
    match config.strategy(Strategy::Cranelift) {
        Ok(o) => o,
        _ => return,
    };

    config
        .debug_info(true)
        .wasm_threads(true)
        .wasm_reference_types(true)
        .wasm_simd(true)
        .wasm_bulk_memory(true)
        .wasm_multi_value(true);

    let store = Store::new(&Engine::new(&config));
    let _module = Module::from_binary(&store, &data);
}

Which Wasmtime version / commit hash / branch are you using?

crate version: wasmtime = "0.15.0"
Wasmtime cli version: wasmtime 0.15.0

@pventuzelo pventuzelo added the bug Incorrect behavior in the current implementation that needs fixing label Apr 25, 2020
@alexcrichton
Copy link
Member

Thanks for the report! There are known issues in the implementations of some wasm proposals right now, and for example reference types are known to not be fully implemented (same with SIMD and threads). Our own fuzzing has a whitelist of which wasm proposals that we fuzz against, and it's specifically not enabling all of them.

This is perhaps something that would be good to update the documentation for though to indicate that some wasm proposals exported from Config are not fully finished yet.

@pventuzelo
Copy link
Contributor Author

Hi Alex,

Oh interesting, effectively I checked the documentation for the different Config fields and it would have been good to have this information highlighted there.

In a more generic way, i'm not a big fan of macros in Rust that can lead to panics so I always prefer to report them even if project is under development.

I let you decided when to close this issue ;)

alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Apr 28, 2020
Be sure to warn users that the entirety of some proposals are not
implemented, so bugs should be expected.

Closes bytecodealliance#1601
abrown pushed a commit that referenced this issue Apr 29, 2020
Be sure to warn users that the entirety of some proposals are not
implemented, so bugs should be expected.

Closes #1601
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect behavior in the current implementation that needs fixing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants