Repository navigation
return error instead of panicking on host stream type mismatch - #14733
Merged
alexcrichton merged 6 commits intoOct 14, 2026
Merged
Conversation
Previously, `UntypedWriteBuffer::get_mut` panicked on type mismatch, which created a hazard for embedders which might receive their own stream back from the guest using a different Rust-level item type despite having the same component-model-level item type. Now we return an error instead.
cfallin
approved these changes
Oct 14, 2026
Member
|
(merge conflict at the moment) |
alexcrichton
enabled auto-merge
October 14, 2026 19:49
github-merge-queue
Bot
removed this pull request from the merge queue due to a conflict with the base branch
Oct 14, 2026
pchickey
pushed a commit
to pchickey/wasmtime
that referenced
this pull request
Oct 19, 2026
This commit fixes an issue where a `StreamAny` can be used to re-type a
future or stream in a manner that can cause a panic within Wasmtime in
certain host situations. The fix here is to unconditionally perform a
type-check when lowering a future or stream into a guest. This is
already required for `{Stream,Future}Any`, and it's additionally
required in this issue when the `T` in `StreamReader<T>` contains a
`StreamAny`, for example. This technically makes the static type-check
of `StreamReader<u32>` redundant, but it seems best to fully close this
hole since bytecodealliance#14733 was not a complete fix for this class of issues.
pchickey
pushed a commit
to pchickey/wasmtime
that referenced
this pull request
Oct 19, 2026
This commit fixes an issue where a `StreamAny` can be used to re-type a
future or stream in a manner that can cause a panic within Wasmtime in
certain host situations. The fix here is to unconditionally perform a
type-check when lowering a future or stream into a guest. This is
already required for `{Stream,Future}Any`, and it's additionally
required in this issue when the `T` in `StreamReader<T>` contains a
`StreamAny`, for example. This technically makes the static type-check
of `StreamReader<u32>` redundant, but it seems best to fully close this
hole since bytecodealliance#14733 was not a complete fix for this class of issues.
pchickey
added a commit
that referenced
this pull request
Oct 19, 2026
* [release-48] wasi-http: Prohibit duplicate content length headers Setting more than one value for content-length is now rejected with HeaderError::InvalidSyntax in p2 and p3. Fixes GHSA-r8xh-cgf7-392j (cherry picked from commit f843085) * [release-48] wasmtime-wasi-http p3: apply forbidden header check to trailers in a backwards-compatible manner by introducing a new WasiHttpHooks::forbidden_header_filter method. Embedders which customized WasiHttpHooks::is_forbidden_header must switch to using this new method in order to block trailers which are not the DEFAULT_FORBIDDEN_HEADERS. Fixes GHSA-jxcf-8qw5-5c33 * [release-48] wasi-http p3: correctly enforce content-length for response bodies The prior implementation did not enforce that this was valid when splicing an existing body into a new response, which made it possible to perform response splitting attacks when responding to a non-spec-compliant client. Fixes GHSA-9prg-84vf-g5fc * Cranelift/aarch64: fix `br_table`s with very large target count. Previously, the `JTSequence` macro-instruction contained a conditional branch for the default (selector greater than table size) case. This default branch on aarch64 has a +/- 1MiB range. The `JTSequence` also contains the entire table of 32-bit offsets for each `br_table` target. As a result of these two facts, a branch may have an out-of-bounds target and silently wrap the offset, resulting in an incorrect branch target. This PR fixes the sequence to instead use the offset table for the default case too. The conditional branch is converted into a conditional-select that clamps the index to the last table entry (which we fill with the default target) if out-of-bounds. * Review feedback. * Review feedback. * 48.0.7: release notes * Centralize type-checks of futures/streams This commit fixes an issue where a `StreamAny` can be used to re-type a future or stream in a manner that can cause a panic within Wasmtime in certain host situations. The fix here is to unconditionally perform a type-check when lowering a future or stream into a guest. This is already required for `{Stream,Future}Any`, and it's additionally required in this issue when the `T` in `StreamReader<T>` contains a `StreamAny`, for example. This technically makes the static type-check of `StreamReader<u32>` redundant, but it seems best to fully close this hole since #14733 was not a complete fix for this class of issues. * release notes: release date, separator --------- Co-authored-by: Chris Fallin <chris@cfallin.org> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
pchickey
added a commit
that referenced
this pull request
Oct 19, 2026
* [release-49] wasi-http: Prohibit duplicate content length headers Setting more than one value for content-length is now rejected with HeaderError::InvalidSyntax in p2 and p3. Fixes GHSA-r8xh-cgf7-392j (cherry picked from commit f843085) * [release-49] wasmtime-wasi-http p3: apply forbidden header check to trailers in a backwards-compatible manner by introducing a new WasiHttpHooks::forbidden_header_filter method. Embedders which customized WasiHttpHooks::is_forbidden_header must switch to using this new method in order to block trailers which are not the DEFAULT_FORBIDDEN_HEADERS. Fixes GHSA-jxcf-8qw5-5c33 * [release-49] wasi-http p3: correctly enforce content-length for response bodies The prior implementation did not enforce that this was valid when splicing an existing body into a new response, which made it possible to perform response splitting attacks when responding to a non-spec-compliant client. Fixes GHSA-9prg-84vf-g5fc * Cranelift/aarch64: fix `br_table`s with very large target count. Previously, the `JTSequence` macro-instruction contained a conditional branch for the default (selector greater than table size) case. This default branch on aarch64 has a +/- 1MiB range. The `JTSequence` also contains the entire table of 32-bit offsets for each `br_table` target. As a result of these two facts, a branch may have an out-of-bounds target and silently wrap the offset, resulting in an incorrect branch target. This PR fixes the sequence to instead use the offset table for the default case too. The conditional branch is converted into a conditional-select that clamps the index to the last table entry (which we fill with the default target) if out-of-bounds. * Review feedback. * Review feedback. * 49.0.4: release notes * Centralize type-checks of futures/streams This commit fixes an issue where a `StreamAny` can be used to re-type a future or stream in a manner that can cause a panic within Wasmtime in certain host situations. The fix here is to unconditionally perform a type-check when lowering a future or stream into a guest. This is already required for `{Stream,Future}Any`, and it's additionally required in this issue when the `T` in `StreamReader<T>` contains a `StreamAny`, for example. This technically makes the static type-check of `StreamReader<u32>` redundant, but it seems best to fully close this hole since #14733 was not a complete fix for this class of issues. * release notes: release date, separator --------- Co-authored-by: Chris Fallin <chris@cfallin.org> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
pchickey
added a commit
that referenced
this pull request
Oct 19, 2026
* [release-50] wasi-http: Prohibit duplicate content length headers Setting more than one value for content-length is now rejected with HeaderError::InvalidSyntax in p2 and p3. Fixes GHSA-r8xh-cgf7-392j (cherry picked from commit f843085) * [release-50] wasmtime-wasi-http p3: apply forbidden header check to trailers by changing the WasiHttpHooks::is_forbidden_header method to WasiHttpHooks::forbidden_header_filter, which is a boxed (arced) closure instead of a direct method. Embedders which customized WasiHttpHooks::is_forbidden_header must switch to using this new method in order to block trailers which are not the DEFAULT_FORBIDDEN_HEADERS. Fixes GHSA-jxcf-8qw5-5c33 * [release-50] wasi-http p3: correctly enforce content-length for response bodies The prior implementation did not enforce that this was valid when splicing an existing body into a new response, which made it possible to perform response splitting attacks when responding to a non-spec-compliant client. Fixes GHSA-9prg-84vf-g5fc * Cranelift/aarch64: fix `br_table`s with very large target count. Previously, the `JTSequence` macro-instruction contained a conditional branch for the default (selector greater than table size) case. This default branch on aarch64 has a +/- 1MiB range. The `JTSequence` also contains the entire table of 32-bit offsets for each `br_table` target. As a result of these two facts, a branch may have an out-of-bounds target and silently wrap the offset, resulting in an incorrect branch target. This PR fixes the sequence to instead use the offset table for the default case too. The conditional branch is converted into a conditional-select that clamps the index to the last table entry (which we fill with the default target) if out-of-bounds. * Review feedback. * Review feedback. * Centralize type-checks of futures/streams This commit fixes an issue where a `StreamAny` can be used to re-type a future or stream in a manner that can cause a panic within Wasmtime in certain host situations. The fix here is to unconditionally perform a type-check when lowering a future or stream into a guest. This is already required for `{Stream,Future}Any`, and it's additionally required in this issue when the `T` in `StreamReader<T>` contains a `StreamAny`, for example. This technically makes the static type-check of `StreamReader<u32>` redundant, but it seems best to fully close this hole since #14733 was not a complete fix for this class of issues. * update release notes with PRs where these landed on main --------- Co-authored-by: Chris Fallin <chris@cfallin.org> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
jrandolf
pushed a commit
to jrandolf/wasmtime
that referenced
this pull request
Oct 19, 2026
This commit fixes an issue where a `StreamAny` can be used to re-type a
future or stream in a manner that can cause a panic within Wasmtime in
certain host situations. The fix here is to unconditionally perform a
type-check when lowering a future or stream into a guest. This is
already required for `{Stream,Future}Any`, and it's additionally
required in this issue when the `T` in `StreamReader<T>` contains a
`StreamAny`, for example. This technically makes the static type-check
of `StreamReader<u32>` redundant, but it seems best to fully close this
hole since bytecodealliance#14733 was not a complete fix for this class of issues.
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
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.
Previously,
UntypedWriteBuffer::get_mutpanicked on type mismatch, which created a hazard for embedders which might receive their own stream back from the guest using a different Rust-level item type despite having the same component-model-level item type. Now we return an error instead.Part of GHSA-63h4-6cx9-pjfj