Prevent using shared memories with Memory#12022
Merged
alexcrichton merged 2 commits intobytecodealliance:mainfrom Nov 11, 2025
Merged
Prevent using shared memories with Memory#12022alexcrichton merged 2 commits intobytecodealliance:mainfrom
Memory#12022alexcrichton merged 2 commits intobytecodealliance:mainfrom
Conversation
This commit fixes a few issues where it was possible to represent a wasm shared linear memory with the `wasmtime::Memory` type. This is not sound because `wasmtime::Memory` provides safe Rust access to the bytes where that is not possible with wasm shared memories. Shared memories in Rust must be represented by `SharedMemory`, not `wasmtime::Memory`. Specifically this commit prevents two vectors of this happening: 1. `Memory::new` now requires that the memory type specified is non-shared. Instead `SharedMemory::new` must be used instead. 2. Core dumps now skip over shared memories when iterating over all memories in the store. Supporting shared memories is left to a future feature request for now.
github-actions
bot
added
the
wasmtime:api
tschneidereit
approved these changes
Nov 11, 2025
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 14, 2025
This fixes fallout from bytecodealliance#12022 which was detected during fuzzing which tried creating a shared memory.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 14, 2025
* Fix `MemoryType::default_value` with shared memories This fixes fallout from #12022 which was detected during fuzzing which tried creating a shared memory. * Fix tests
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 17, 2025
This commit is borne out of a fuzz bug that was opened recently. The fuzz bug specifically has to do with fallout from bytecodealliance#12022, specifically `SharedMemory` being used to allocated instead of `Memory`. In this situation the resource limiter is no longer consulted meaning that shared memories bypass this and aren't caught by OOM checks. This is currently by design because `SharedMemory` instances don't know which resource limiter to hook into per-store. More generally though the implementation of wasm threads, while workable in Wasmtime, has a number of known relatively large deficiencies. These were not resolved prior to ungating the wasm proposal (that's on me) but nevertheless the quality of implementation is not quite up to "tier 1 par" with the rest of what Wasmtime offers. Given that I'm proposing that threads is downgraded to tier 2 for now which means, primarily, that we won't issue CVEs for issues with it. The proposal is still on-by-default and usable-by-default, but my hope is to reflect the current level of quality in Wasmtime with this adjustment. This commit shuffles around some documentation of wasm proposals to split it into tier 1/2/3 instead of on/off-by-default and then adds a column for whether the proposal is on-by-default.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 21, 2025
This commit is borne out of a fuzz bug that was opened recently. The fuzz bug specifically has to do with fallout from bytecodealliance#12022, specifically `SharedMemory` being used to allocated instead of `Memory`. In this situation the resource limiter is no longer consulted meaning that shared memories bypass this and aren't caught by OOM checks. This is currently by design because `SharedMemory` instances don't know which resource limiter to hook into per-store. More generally though the implementation of wasm threads, while workable in Wasmtime, has a number of known relatively large deficiencies. These were not resolved prior to ungating the wasm proposal (that's on me) but nevertheless the quality of implementation is not quite up to "tier 1 par" with the rest of what Wasmtime offers. Given this the threads proposal is now downgraded to tier 2. To help minimize the impact of this the wasm proposal is left enabled-by-default, but creation of a `SharedMemory` in the Rust API requires opting-in via a new `Config::shared_memory` method. This commit shuffles around some documentation of wasm proposals to split it into tier 1/2/3 instead of on/off-by-default and then adds a column for whether the proposal is on-by-default.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Nov 24, 2025
This commit is borne out of a fuzz bug that was opened recently. The fuzz bug specifically has to do with fallout from bytecodealliance#12022, specifically `SharedMemory` being used to allocated instead of `Memory`. In this situation the resource limiter is no longer consulted meaning that shared memories bypass this and aren't caught by OOM checks. This is currently by design because `SharedMemory` instances don't know which resource limiter to hook into per-store. More generally though the implementation of wasm threads, while workable in Wasmtime, has a number of known relatively large deficiencies. These were not resolved prior to ungating the wasm proposal (that's on me) but nevertheless the quality of implementation is not quite up to "tier 1 par" with the rest of what Wasmtime offers. Given this the threads proposal is now downgraded to tier 2. To help minimize the impact of this the wasm proposal is left enabled-by-default, but creation of a `SharedMemory` in the Rust API requires opting-in via a new `Config::shared_memory` method. This commit shuffles around some documentation of wasm proposals to split it into tier 1/2/3 instead of on/off-by-default and then adds a column for whether the proposal is on-by-default.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 24, 2025
* "Downgrade" threads support to tier 2, disable fuzzing This commit is borne out of a fuzz bug that was opened recently. The fuzz bug specifically has to do with fallout from #12022, specifically `SharedMemory` being used to allocated instead of `Memory`. In this situation the resource limiter is no longer consulted meaning that shared memories bypass this and aren't caught by OOM checks. This is currently by design because `SharedMemory` instances don't know which resource limiter to hook into per-store. More generally though the implementation of wasm threads, while workable in Wasmtime, has a number of known relatively large deficiencies. These were not resolved prior to ungating the wasm proposal (that's on me) but nevertheless the quality of implementation is not quite up to "tier 1 par" with the rest of what Wasmtime offers. Given this the threads proposal is now downgraded to tier 2. To help minimize the impact of this the wasm proposal is left enabled-by-default, but creation of a `SharedMemory` in the Rust API requires opting-in via a new `Config::shared_memory` method. This commit shuffles around some documentation of wasm proposals to split it into tier 1/2/3 instead of on/off-by-default and then adds a column for whether the proposal is on-by-default. * clangformat * Fix tests * Add tests for failed creation Fix an issue where defined shared memories weren't gated * Sync disabled threads stub * Fix another test prtest:full * Fix fuzzing tests * Fix dwarf tests
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit fixes a few issues where it was possible to represent a wasm shared linear memory with the
wasmtime::Memorytype. This is not sound becausewasmtime::Memoryprovides safe Rust access to the bytes where that is not possible with wasm shared memories. Shared memories in Rust must be represented bySharedMemory, notwasmtime::Memory.Specifically this commit prevents two vectors of this happening:
Memory::newnow requires that the memory type specified is non-shared. InsteadSharedMemory::newmust be used instead.Core dumps now skip over shared memories when iterating over all memories in the store. Supporting shared memories is left to a future feature request for now.