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

A abort failure in wasm::WasmBinaryBuilder::visitRethrow(wasm::Rethrow*) #4410

Closed
ZFeiXQ opened this issue Dec 25, 2021 · 8 comments
Closed

Comments

@ZFeiXQ
Copy link

ZFeiXQ commented Dec 25, 2021

Version:

version_104

command:

./bin/wasm-ctor-eval POC5

POC5.zip

Result

76703 abort 

bt

Program received signal SIGABRT, Aborted.
[----------------------------------registers-----------------------------------]
RAX: 0x0 
RBX: 0x7ffff6d47fc0 (0x00007ffff6d47fc0)
RCX: 0x7ffff6ee118b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
RDX: 0x0 
RSI: 0x7fffffffcbe0 --> 0x0 
RDI: 0x2 
RBP: 0x7ffff7056588 ("%s%s%s:%u: %s%sAssertion `%s' failed.\n%n")
RSP: 0x7fffffffcbe0 --> 0x0 
RIP: 0x7ffff6ee118b (<__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108])
R8 : 0x0 
R9 : 0x7fffffffcbe0 --> 0x0 
R10: 0x8 
R11: 0x246 
R12: 0x7ffff7e4e3d8 ("/home/zxq/CVE_testing/source/binaryen/src/wasm/wasm-binary.cpp")
R13: 0x1964 
R14: 0x7ffff7e4f588 ("curr->target != DELEGATE_CALLER_TARGET")
R15: 0x5555555f7030 --> 0x30246c6562616c ('label$0')
EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x7ffff6ee117f <__GI_raise+191>:	mov    edi,0x2
   0x7ffff6ee1184 <__GI_raise+196>:	mov    eax,0xe
   0x7ffff6ee1189 <__GI_raise+201>:	syscall 
=> 0x7ffff6ee118b <__GI_raise+203>:	mov    rax,QWORD PTR [rsp+0x108]
   0x7ffff6ee1193 <__GI_raise+211>:	xor    rax,QWORD PTR fs:0x28
   0x7ffff6ee119c <__GI_raise+220>:	jne    0x7ffff6ee11c4 <__GI_raise+260>
   0x7ffff6ee119e <__GI_raise+222>:	mov    eax,r8d
   0x7ffff6ee11a1 <__GI_raise+225>:	add    rsp,0x118
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffcbe0 --> 0x0 
0008| 0x7fffffffcbe8 --> 0x7ffff6f38850 (<__GI___libc_free>:	endbr64)
0016| 0x7fffffffcbf0 --> 0x7ffffbad8000 
0024| 0x7fffffffcbf8 --> 0x5555555e7920 --> 0x0 
0032| 0x7fffffffcc00 --> 0x5555555e7985 ("inaryBuilder::visitRethrow(wasm::Rethrow*): Assertion `curr->target != DELEGATE_CALLER_TARGET' failed.\n")
0040| 0x7fffffffcc08 --> 0x5555555e7920 --> 0x0 
0048| 0x7fffffffcc10 --> 0x5555555e7920 --> 0x0 
0056| 0x7fffffffcc18 --> 0x5555555e79ec --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGABRT
__GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
gdb-peda$ 
gdb-peda$ bt
#0  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff6ec0859 in __GI_abort () at abort.c:79
#2  0x00007ffff6ec0729 in __assert_fail_base (fmt=0x7ffff7056588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff7e4f588 "curr->target != DELEGATE_CALLER_TARGET", 
    file=0x7ffff7e4e3d8 "/home/zxq/CVE_testing/source/binaryen/src/wasm/wasm-binary.cpp", line=0x1964, function=<optimized out>) at assert.c:92
#3  0x00007ffff6ed1f36 in __GI___assert_fail (assertion=0x7ffff7e4f588 "curr->target != DELEGATE_CALLER_TARGET", file=0x7ffff7e4e3d8 "/home/zxq/CVE_testing/source/binaryen/src/wasm/wasm-binary.cpp", 
    line=0x1964, function=0x7ffff7e4f548 "void wasm::WasmBinaryBuilder::visitRethrow(wasm::Rethrow*)") at assert.c:101
#4  0x00007ffff7c09ca1 in wasm::WasmBinaryBuilder::visitRethrow(wasm::Rethrow*) () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#5  0x00007ffff7c0b48c in wasm::WasmBinaryBuilder::readExpression(wasm::Expression*&) () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#6  0x00007ffff7c0c17e in wasm::WasmBinaryBuilder::processExpressions() () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#7  0x00007ffff7c0ff90 in wasm::WasmBinaryBuilder::getBlockOrSingleton(wasm::Type) () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#8  0x00007ffff7c109bb in wasm::WasmBinaryBuilder::readFunctions() () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#9  0x00007ffff7c11f52 in wasm::WasmBinaryBuilder::read() () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#10 0x00007ffff7c3dec6 in wasm::ModuleReader::readBinaryData(std::vector<char, std::allocator<char> >&, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
   from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#11 0x00007ffff7c3e6cc in wasm::ModuleReader::readBinary(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#12 0x00007ffff7c3eda1 in wasm::ModuleReader::read(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, wasm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) () from /home/zxq/CVE_testing/source/binaryen/build/bin/../lib/libbinaryen.so
#13 0x000055555556943e in main ()
#14 0x00007ffff6ec20b3 in __libc_start_main (main=0x5555555688c0 <main>, argc=0x2, argv=0x7fffffffe338, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe328)
    at ../csu/libc-start.c:308
#15 0x0000555555569e5e in _start ()

@aheejin
Copy link
Member

aheejin commented Dec 28, 2021

The file doesn't seem to be a valid wasm file. How did you generate it?

@ZFeiXQ
Copy link
Author

ZFeiXQ commented Dec 29, 2021

The file is generated by fuzz testing

@aheejin
Copy link
Member

aheejin commented Dec 29, 2021

Which fuzzer do you mean? If you mean Binaryen fuzzer, it prints a seed with which you can reproduce the error. You can report the bug with your version and the seed. If you are unsure what seed is, you can attach the whole error message from the fuzzer.

If you mean another fuzzer, that fuzzer can have a bug, but we don't have any idea, because it's not ours.

@ZFeiXQ
Copy link
Author

ZFeiXQ commented Dec 29, 2021

I use the genertated POC5 as a input to execute the program, the assertion is happen(POC5 is generated by the fuzzer, but the program is installed normally):

./wasm-ctor-eval ../../../../POC5 
wasm-ctor-eval: /home/zxq/CVE_testing/source/binaryen/src/wasm/wasm-binary.cpp:6500: void wasm::WasmBinaryBuilder::visitRethrow(wasm::Rethrow*): Assertion `curr->target != DELEGATE_CALLER_TARGET' failed.
[1]    3409714 abort      ./wasm-ctor-eval ../../../../POC5

If you think this problem is caused by unvalid input, please ignore it, the input is indeed malformed data.

Thank you.

@aheejin
Copy link
Member

aheejin commented Dec 29, 2021

POC5 is generated by the fuzzer, but the program is installed normally

Are you talking about the Binaryen fuzzer? If so please report the bug with the seed. If Binaryen fuzzer generated an invalid wasm file, it should have errored out with a meaningful error message, which contains the seed.

@ZFeiXQ
Copy link
Author

ZFeiXQ commented Dec 29, 2021

The POC5 is not generated by Binaryen fuzzer.
Thank you.

@aheejin
Copy link
Member

aheejin commented Dec 30, 2021

OK. I'll close this and your other issues about similar topics for now then. Please feel free to reopen if necessary.

@kripken
Copy link
Member

kripken commented Jan 5, 2022

I looked at two of these now and opened quick PRs. Overall I think improving errors on invalid inputs is generally worthwhile, but definitely very low priority. Real users are extremely unlikely to be hit by these errors. This is just not where our main source of bugs is. So, yeah, I'm not sure it's worth filing these to be honest.

But we would be very interested in any functional bugs that you can find @ZFeiXQ , that is, on valid inputs - things like a pass changing the behavior of the wasm, or a pass being nondeterministic, or infinite looping, etc.

Alternatively, invalid inputs that are generated by real-world tools (like if LLVM somehow emits a bad wasm file) would be very interesting as well.

kripken added a commit that referenced this issue Jan 5, 2022
#4422)

Without this, the result in a build without assertions might be quite
confusing. See #4410

Also make the internal names more obviously internal names.
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