alexcrichton opened PR #14730 from alexcrichton:fix-same-instance-adapter to bytecodealliance:main:
This commit fixes an accidental regression from #14146 where if a same-instance lift/lower transferring a string provided overlapping ranges for a string transcode it could cause a panic on the host. The changes in #14146 are downstream of various spec changes which have adjusted rules in this precise scenario over time, and technically the spec allows these sorts of calls in its current iteration. All of component-to-component adaptation in Wasmtime, however, assumes that the precise order of operations is not semantically visible which is violated should same-instance adaptations be allowed. The fix here is to restore a trap in same-instance adaptations, and the next steps here will be to have a follow-up with the spec to figure out a long-term solution.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.mdPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton requested cfallin for a review on PR #14730.
alexcrichton requested wasmtime-core-reviewers for a review on PR #14730.
alexcrichton edited PR #14730:
This commit fixes an accidental regression from #14146 where if a same-instance lift/lower transferring a string provided overlapping ranges for a string transcode it could cause a panic on the host. The changes in #14146 are downstream of various spec changes which have adjusted rules in this precise scenario over time, and technically the spec allows these sorts of calls in its current iteration. All of component-to-component adaptation in Wasmtime, however, assumes that the precise order of operations is not semantically visible which is violated should same-instance adaptations be allowed. The fix here is to restore a trap in same-instance adaptations, and the next steps here will be to have a follow-up with the spec to figure out a long-term solution.
Part of https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-54p9-vhhq-8f7q
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.mdPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
:thumbs_up: cfallin submitted PR review.
cfallin added PR #14730 Restore a trap in same-instance adapter calls to the merge queue.
cfallin removed PR #14730 Restore a trap in same-instance adapter calls from the merge queue.
:check: cfallin merged PR #14730.
Last updated: Oct 31 2026 at 23:03 UTC