Wasmtime GitHub notifications bot (Oct 07 2025 at 17:38): Wasmtime GitHub notifications bot (Oct 07 2025 at 17:38):dan-bishopfox opened issue #11804:
I can reliably reproduce a crash in wasmtime wasi p2 sockets.
The setup for it is a bit complex, so I made a minimal repo to reproduce it. Instructions are there in the readme.
https://github.com/dan-bishopfox/crash_wasiBasically, we just use TCP sockets from within Wasm WASI p2 code and it crashes. Nothing special beyond that. The scaffolding in the repo is just there to setup some sample code that loads and runs the Wasm.
Let me know if there's anything else you need or if you have any issue reproducing it.
Thanks!
Wasmtime GitHub notifications bot (Oct 07 2025 at 17:38):dan-bishopfox added the bug label to Issue #11804.
Wasmtime GitHub notifications bot (Oct 07 2025 at 17:51):tschneidereit commented on issue #11804:
@dan-bishopfox thank you for reporting this. The Repo with the PoC isn't public it seems, PLEASE KEEP IT THAT WAY!
Process crashes are denial-of-service attack vectors, so we'd like to be able to disclose them responsibly.
If you could give the @bytecodealliance/wasmtime-core team access to the repo or otherwise share it privately with us, that'd greatly appreciated!
Wasmtime GitHub notifications bot (Oct 07 2025 at 17:53):dan-bishopfox commented on issue #11804:
Sure thing! I didn't notice you considered that a security issue sorry.
Wasmtime GitHub notifications bot (Oct 07 2025 at 17:56):tschneidereit commented on issue #11804:
Nothing to be sorry about: while that'd make our lives easier, we certainly don't have the expectation that everyone knows our exact definition of security issues :)
And again, thank you for the report!
Wasmtime GitHub notifications bot (Oct 07 2025 at 17:58):dan-bishopfox commented on issue #11804:
@tschneidereit I don't see the
@bytecodealliance/wasmtime-coreteam in github...<img width="869" height="344" alt="Image" src="https://github.com/user-attachments/assets/e13b1ce0-8065-44bf-8d9d-d156b06ff072" />
Wasmtime GitHub notifications bot (Oct 07 2025 at 18:01):tschneidereit commented on issue #11804:
oh, apparently teams are only visible within an organization, my apologies. Maybe you can invite me, @alexcrichton, and @pchickey and we do anything else necessary?
Wasmtime GitHub notifications bot (Oct 07 2025 at 18:04):dan-bishopfox commented on issue #11804:
Added the three of you
Wasmtime GitHub notifications bot (Oct 07 2025 at 18:07):pchickey commented on issue #11804:
Thanks I will take a look today
Wasmtime GitHub notifications bot (Oct 07 2025 at 18:09):alexcrichton commented on issue #11804:
I took a look and this isn't a security issue, so @dan-bishopfox feel free to go ahead and make the repo public. "Crash" for us typically means a panic in the host or similar, but the crash in this case is a trap in the guest, which while it may indicate a bug is not a security issue.
At a cursory glance it looks like this is a bug in the guest, but we can dig in more later.
Wasmtime GitHub notifications bot (Oct 07 2025 at 19:09):tschneidereit commented on issue #11804:
Thank you for investigating, Alex! And again, even if this turns out not to be a bug in Wasmtime at all, we appreciate you taking the time to put together the report and reproducer, @dan-bishopfox!
Wasmtime GitHub notifications bot (Oct 07 2025 at 19:10):dan-bishopfox commented on issue #11804:
Backtrace:
guest error: Some(error while executing at wasm backtrace: 0: 0x4a18 - guest-7a94999886812cfa.wasm!<wasi::bindings::wasi::sockets::tcp::TcpSocket as wasi::bindings::_rt::WasmResource>::drop::hbd600976671ef7ed 1: 0x35e9 - guest-7a94999886812cfa.wasm!<wasi::bindings::_rt::Resource<T> as core::ops::drop::Drop>::drop::hc26cd29c2e86015f 2: 0x3564 - guest-7a94999886812cfa.wasm!core::ptr::drop_in_place<wasi::bindings::_rt::Resource<wasi::bindings::wasi::sockets::tcp::TcpSocket>>::he71c56c6c7df9336 3: 0x3b89 - guest-7a94999886812cfa.wasm!core::ptr::drop_in_place<wasi::bindings::wasi::sockets::tcp::TcpSocket>::hc04eeeba95d43492 4: 0x2542 - guest-7a94999886812cfa.wasm!guest::run::hd31b4c5c8b2f2f83 5: 0x1e59 - guest-7a94999886812cfa.wasm!guest::main::hda5a2cfc9bf0b36d 6: 0x3463 - guest-7a94999886812cfa.wasm!core::ops::function::FnOnce::call_once::ha3371c02f905880a 7: 0x4308 - guest-7a94999886812cfa.wasm!std::sys::backtrace::__rust_begin_short_backtrace::h9a0efd7171e138ad 8: 0x40ca - guest-7a94999886812cfa.wasm!std::rt::lang_start::{{closure}}::h850807c2aa8d5152 9: 0x1069b - guest-7a94999886812cfa.wasm!std::rt::lang_start_internal::hd8f43a585ee7e12a 10: 0x407c - guest-7a94999886812cfa.wasm!std::rt::lang_start::hcc01919a26f87998 11: 0x2fcb - guest-7a94999886812cfa.wasm!__main_void 12: 0x1840 - guest-7a94999886812cfa.wasm!_start 13: 0x306b42 - wit-component:adapter:wasi_snapshot_preview1!wasi:cli/run@0.2.3#run note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information Caused by: resource has children)Also, I updated the sample code to print the backtrace. (should have done that from the start)
Wasmtime GitHub notifications bot (Oct 07 2025 at 21:11):pchickey commented on issue #11804:
Instead of creating your own host, this should be reproducible using wasmtime-cli, which would make things easier for us.
I haven't tried to debug it, but based on the
resource has childrenerror my suspicion is that Rust's automatic dropping order of thein_stream,out_stream, andsocketbindings are not in the order that wasi-sockets requires, which is forin_streamandout_streamto be dropped before thesocketis dropped, so you could try to manually writedrop(in_stream); drop(out_stream); drop(socket);at the end of this function to resolve that.
Wasmtime GitHub notifications bot (Oct 07 2025 at 21:20):dan-bishopfox commented on issue #11804:
You might be right. I added:
drop(in_stream); drop(out_stream); drop(socket);And the crash doesn't seem to reproduce anymore. I hit the:
This will never be printed. Because it crashes before we get here.line.
It's a good workaround for the time-being anyway
Wasmtime GitHub notifications bot (Oct 07 2025 at 21:31):pchickey commented on issue #11804:
That drop order restriction goes away in wasip3, but you'll have to live with it in wasip2 for now.
I'd suggest that you use wstd, which papers over a lot of the not so great parts of the wasip2 bindings, but it doesn't actually have support for tcp connect right now. It could be added, but I'm in the middle of various other things on it currently.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:24):alexcrichton closed issue #11804:
I can reliably reproduce a crash in wasmtime wasi p2 sockets.
The setup for it is a bit complex, so I made a minimal repo to reproduce it. Instructions are there in the readme.
https://github.com/dan-bishopfox/crash_wasiBasically, we just use TCP sockets from within Wasm WASI p2 code and it crashes. Nothing special beyond that. The scaffolding in the repo is just there to setup some sample code that loads and runs the Wasm.
Let me know if there's anything else you need or if you have any issue reproducing it.
Thanks!
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:24):alexcrichton commented on issue #11804:
Ah ok, yes indeed! In that case I don't believe that this is a bug in Wasmtime, so I'm going to close this.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:30):dan-bishopfox commented on issue #11804:
Where should I report this to then? For tracking until it's properly fixed? Or is the answer that it's likely to just not be fixed in wasi p2?
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:31):alexcrichton commented on issue #11804:
Yeah wasip2 won't be changing at this point so the bug is in the guest mostly, where it needs to interface with APIs differently.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:34):dan-bishopfox commented on issue #11804:
Perhaps just a documentation change to
create_tcp_socketto make it clear that the TcpSocket object has to be drop'ed last (after the in/out streams). Since otherwise that fact's not obvious.
Wasmtime GitHub notifications bot (Oct 07 2025 at 22:37):alexcrichton commented on issue #11804:
Sure yeah! For doc updates to WASI APIs you can send PRs to the repositories themselves, such as https://github.com/WebAssembly/wasi-sockets/
Wasmtime GitHub notifications bot (Oct 10 2025 at 20:40):dan-bishopfox commented on issue #11804:
Hey, sorry to bug you all again but I ran into another crash that looks related. I added the manual
dropcode in the order ofInputStream->OutputStream->TcpSocket. But it's theInputStreamthis time that's complaining.0: 0x4199e - guest-561fe04e002e2417.wasm!_ZN100_$LT$wasi..bindings..wasi..io..streams..InputStream$u20$as$u20$wasi..bindings.._rt..WasmResource$GT$4drop17ha956dcecfc0cbaa7E 1: 0x291ff - guest-561fe04e002e2417.wasm!_ZN80_$LT$wasi..bindings.._rt..Resource$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$4drop17he5627ea0b2554dd0E 2: 0x291ad - guest-561fe04e002e2417.wasm!_ZN4core3ptr104drop_in_place$LT$wasi..bindings.._rt..Resource$LT$wasi..bindings..wasi..io..streams..InputStream$GT$$GT$17h65226a4f2f498a40E 3: 0x2ab16 - guest-561fe04e002e2417.wasm!_ZN4core3ptr67drop_in_place$LT$wasi..bindings..wasi..io..streams..InputStream$GT$17hd1a71f0212bef4d7E 4: 0x2a5fe - guest-561fe04e002e2417.wasm!_ZN4core3ptr95drop_in_place$LT$core..option..Option$LT$wasi..bindings..wasi..io..streams..InputStream$GT$$GT$17hc491081ad7572c7fE 5: 0x2a572 - guest-561fe04e002e2417.wasm!_ZN4core3ptr63drop_in_place$LT$guest..commands..core..proxy..SocksProxy$GT$17ha2600ea8687860acE 6: 0x2b61c - guest-561fe04e002e2417.wasm!_ZN4core3ptr91drop_in_place$LT$core..option..Option$LT$guest..commands..core..proxy..SocksProxy$GT$$GT$17h3ce2633f2d544ea0E > This is my business logic function here. 7: 0x14d3d - guest-561fe04e002e2417.wasm!_ZN7guest23handle_async_proxy_data17h35916648c6278204E 8: 0x17072 - guest-561fe04e002e2417.wasm!_ZN7guest3run17h035dd1919c4b29b8E 9: 0x17c35 - guest-561fe04e002e2417.wasm!_ZN7guest4main17h355a4d4b6be6a3aeE 10: 0x28f4c - guest-561fe04e002e2417.wasm!_ZN4core3ops8function6FnOnce9call_once17h665b2f14ac85f0eaE 11: 0x1ddee - guest-561fe04e002e2417.wasm!_ZN3std3sys9backtrace28__rust_begin_short_backtrace17h973638772f410a9eE 12: 0x7cdf - guest-561fe04e002e2417.wasm!_ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h8206f535aef5eeb8E 13: 0x262d03 - guest-561fe04e002e2417.wasm!_ZN3std2rt19lang_start_internal17h606819bf9b1f641dE 14: 0x7ca5 - guest-561fe04e002e2417.wasm!_ZN3std2rt10lang_start17hd5c9a870f35d74dcE 15: 0x17c5c - guest-561fe04e002e2417.wasm!__main_void 16: 0x7a12 - guest-561fe04e002e2417.wasm!_start 17: 0x20bd16d - wit-component:adapter:wasi_snapshot_preview1!wasi:cli/run@0.2.6#runIs there something obvious in this that I might be doing wrong? Some other resource that needs to be cleaned up in a potentially undocumented way?
Wasmtime GitHub notifications bot (Oct 10 2025 at 21:02):pchickey commented on issue #11804:
The Pollable associated with the InputStream needs to be dropped before the InputStream
Wasmtime GitHub notifications bot (Oct 10 2025 at 21:03):pchickey edited a comment on issue #11804:
The Pollable associated with the InputStream (got from InputStream::subscribe) needs to be dropped before the InputStream
Wasmtime GitHub notifications bot (Oct 10 2025 at 21:27):dan-bishopfox commented on issue #11804:
That did the trick! Thanks a lot!
Last updated: Dec 06 2025 at 07:03 UTC