You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@thomcc points out that when we abort on wasm32-unknown-unknown, there's nothing actually stopping whoever invoked that module from calling back into it. That's bad, it leads to unsoundness! We should either find some way to prevent this (I don't know how wasm works, maybe there's a global flag we can set on abort and check on every entry point), or we should at least document this prominently, in some place that people using this target are likely to see.
The wasi and emcscripten targets are not affected, they already "poison" modules on abort so they cannot be re-entered.
The text was updated successfully, but these errors were encountered:
RalfJung
added
I-unsound
Issue: A soundness hole (worst kind of bug), see: https://en.wikipedia.org/wiki/Soundness
O-wasm
Target: WASM (WebAssembly), http://webassembly.org/
labels
Oct 29, 2023
rustbot
added
I-prioritize
Issue: Indicates that prioritization has been requested for this issue.
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
labels
Oct 29, 2023
@thomcc points out that when we abort on wasm32-unknown-unknown, there's nothing actually stopping whoever invoked that module from calling back into it. That's bad, it leads to unsoundness! We should either find some way to prevent this (I don't know how wasm works, maybe there's a global flag we can set on abort and check on every entry point), or we should at least document this prominently, in some place that people using this target are likely to see.
The wasi and emcscripten targets are not affected, they already "poison" modules on abort so they cannot be re-entered.
The text was updated successfully, but these errors were encountered: