wasmparser: reject function bodies larger than implementation limit. #2302
Conversation
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
The implementation limits for JS embedders at [1] describe various upper bounds for entities in Wasm modules, including the size of a single function body in bytes. wasmparser is not strictly required to abide by these implementation limits because they are conventions for the JS embedding of Wasm rather than part of the core Wasm standard. However, it does seem to enforce other limits, such as the number of types or locals; this PR updates it to enforce function body size as well. This came up in bytecodealliance/wasmtime#11682, where a very large function (larger than the implementation limit) led to out-of-bounds SSA value numbers in Cranelift when they exceeded the range allowed by our data-structure bitpacking. Rather than doing major surgery to plumb the exact failure through all of Cranelift (including its public API being `Result`-ified on every builder interface) it seems better to have a single limit on the size of incoming functions. It turns out that the Wasm implementation limits were designed for just this purpose, so let's use them in our tooling as well. [1]: https://webassembly.github.io/spec/js-api/#limits
cfallin
commented
Sep 12, 2025
| pub const MAX_WASM_DATA_SEGMENTS: usize = 100_000; | ||
| pub const MAX_WASM_STRING_SIZE: usize = 100_000; | ||
| pub const MAX_WASM_FUNCTION_SIZE: usize = 128 * 1024; | ||
| pub const MAX_WASM_FUNCTION_SIZE: usize = 7_654_321; |
Member
Author
There was a problem hiding this comment.
I'll note that I'm not entirely sure what was going on with the previous limit of 128K here -- it wasn't actually used to enforce function-size limits (despite the name of the constant), only the number of branch-table targets. Given the name it seems reasonable to use it for what it says on the tin.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
The implementation limits for JS embedders at 1 describe various upper bounds for entities in Wasm modules, including the size of a single function body in bytes. wasmparser is not strictly required to abide by these implementation limits because they are conventions for the JS embedding of Wasm rather than part of the core Wasm standard. However, it does seem to enforce other limits, such as the number of types or locals; this PR updates it to enforce function body size as well.
This came up in bytecodealliance/wasmtime#11682, where a very large function (larger than the implementation limit) led to out-of-bounds SSA value numbers in Cranelift when they exceeded the range allowed by our data-structure bitpacking. Rather than doing major surgery to plumb the exact failure through all of Cranelift (including its public API being
Result-ified on every builder interface) it seems better to have a single limit on the size of incoming functions. It turns out that the Wasm implementation limits were designed for just this purpose, so let's use them in our tooling as well.