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

[wasm2wat] Incorrect rejection of valid module #1455

Open
pventuzelo opened this issue Jun 9, 2020 · 2 comments
Open

[wasm2wat] Incorrect rejection of valid module #1455

pventuzelo opened this issue Jun 9, 2020 · 2 comments
Assignees

Comments

@pventuzelo
Copy link

Hi,

During fuzzing I found that the following module was consider invalid by wabt due to a leb128 parsing error. Binaryen choose to "reject" this module but precise that it is a valid module. Other tools like wasmer, wasmtime and wasm-tools valid this module.

Reproducing

Download:
reject_leb128_wabt.zip

WABT:

$ ./wasm-validate reject_leb128_wabt.wasm 
0000016: error: unable to read u32 leb128: table_size

Other tools:

# binaryen
$ wasm-opt reject_leb128_wabt.wasm
wasm-opt reject_leb128_wabt2.wasm
[parse exception: inline string contains NULL (0). that is technically valid in wasm, but you shouldn't do it, and it's not supported in binaryen (at 0:34)]
Fatal: error parsing wasm
# wasmer
$ wasmer validate reject_leb128_wabt2.wasm
# wasm-tools
$ ./wasm-tools/target/debug/wasm-validate-rs reject_leb128_wabt.wasm
$ ./wasm-tools/target/debug/wasm2wat-rs reject_leb128_wabt.wasm
(module
  (type (;0;) (func (param i32 i32 f64)))
  (type (;1;) (func (param i32 i32) (result f64)))
  (type (;2;) (func (param i32 i32)))
  (type (;3;) (func (result f64)))
  (type (;4;) (func (param i32) (result f64)))
  (type (;5;) (func))
  (import "env" "memoryBase" (global (;0;) i32))
  (import "env" "memory" (memory (;0;) 0 2))
  (import "e`v" "table" (table (;0;) 0 funcref))
  (import "^^v" "tableBase" (global (;1;) i32))
)

Branch: master
commit: 15264cd

@binji
Copy link
Member

binji commented Jun 9, 2020

This is an "error" because the custom dynlink section is malformed. wasm-validate currently fails in this case, but will just produce only a warning if run with --ignore-custom-section-errors. Perhaps this is the wrong default? @sbc100 wdyt?

@sbc100
Copy link
Member

sbc100 commented Jun 9, 2020

Perhaps we should make it clear when the error is from a custom section? And point users to --ignore-custom-section-errors in the error message?

Also, perhaps that flag is misnamed, since "ignore" and "only-warn" are two different things, no?

@binji binji self-assigned this Jun 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants