Headline

GHSA-4h67-722j-5pmc: Wasmtime vulnerable to segfault when using component resources

Impact

The implementation of component-model related host-to-wasm trampolines in Wasmtime contained a bug where it’s possible to carefully craft a component, which when called in a specific way, would crash the host with a segfault or assert failure. This bug was introduced in the release of Wasmtime 38.0.0 and affects it subsequent patch releases of 38.0.1 and 38.0.2. No other versions of Wasmtime are affected.

In Wasmtime 38 the implementation of host-to-wasm trampolines was refactored to remove the old usage of setjmp and longjmp to unwind the stack. In this transition, however, trampolines for component-model intrinsics were accidentally not updated meaning that they didn’t update runtime data structures as the other host-to-wasm trampolines did. If an error ocurred during execution of wasm it would then try to read this runtime data which isn’t present, and processing it could then result in a crash. For example one piece of runtime data is where to jump to in the case of a trap, and this is intended to be updated by trampolines during their execution. In this situation the trampoline didn’t do anything meaning that the value was left set to 0 meaning that execution would jump to the 0 address and deterministically crash the program with a segfault.

Component intrinsic host-to-wasm trampolines are not typically used in most situations. These only exist for carefully crafted components no toolchain would conventionally produce. For example if the resource.rep intrinsic were directly lifted without having any other wasm in play then it would use the component intrinsic host-to-wasm trampoline. This effectively means that any component required to trigger this bug would have to be carefully crafted for this specific issue. Furthermore triggering this bug would require that these intrinsics are called from the host which requires specific type signatures to be used. Not all embeddings may be invoking functions with exactly the right type signatures, meaning that even if a component could be crafted a pre-built embedding may still not be able to run the component.

Overall the goal of Wasmtime’s API is that, without unsafe in Rust, it should not be possible to crash the runtime. With Wasmtime 38.0.{0,1,2} it is possible to crash the runtime, however, hence this security issue. Actually exploiting this in practice would require (a) carefully crafted components, (b) a very specific host embedder using the right type signatures, and © a host that updated to 38.0.{0,1,2} within the last few days (38.0.0 was released on 2025-10-20, and this is being published on 2025-10-24). This likely means that almost no embedding is affected, but this security issue is nonetheless being posted for awareness.

Patches

Wasmtime 38.0.3 has been released and is patched to fix this issue.

Workarounds

Affected embeddings have no workaround other than updating to 38.0.3. Users of 37.0.x and prior are not affected. Embeddings that only work with core wasm are not affected. Embeddings may only be affected if functions of specific component type signatures are used/invoked, meaning that if all the prior conditions hold the embedding would need to be audited to see if it’s affected.

References

The PR which refactored setjmp/longjmp usage and introduced this issue is https://github.com/bytecodealliance/wasmtime/pull/11592.

5 hours ago

ghsa

Open in Source

#git

Impact

In Wasmtime 38 the implementation of host-to-wasm trampolines was refactored to remove the old usage of setjmp and longjmp to unwind the stack. In this transition, however, trampolines for component-model intrinsics were accidentally not updated meaning that they didn’t update runtime data structures as the other host-to-wasm trampolines did. If an error ocurred during execution of wasm it would then try to read this runtime data which isn’t present, and processing it could then result in a crash. For example one piece of runtime data is where to jump to in the case of a trap, and this is intended to be updated by trampolines during their execution. In this situation the trampoline didn’t do anything meaning that the value was left set to 0 meaning that execution would jump to the 0 address and deterministically crash the program with a segfault.

Component intrinsic host-to-wasm trampolines are not typically used in most situations. These only exist for carefully crafted components no toolchain would conventionally produce. For example if the resource.rep intrinsic were directly lifted without having any other wasm in play then it would use the component intrinsic host-to-wasm trampoline. This effectively means that any component required to trigger this bug would have to be carefully crafted for this specific issue. Furthermore triggering this bug would require that these intrinsics are called from the host which requires specific type signatures to be used. Not all embeddings may be invoking functions with exactly the right type signatures, meaning that even if a component could be crafted a pre-built embedding may still not be able to run the component.

Overall the goal of Wasmtime’s API is that, without unsafe in Rust, it should not be possible to crash the runtime. With Wasmtime 38.0.{0,1,2} it is possible to crash the runtime, however, hence this security issue. Actually exploiting this in practice would require (a) carefully crafted components, (b) a very specific host embedder using the right type signatures, and © a host that updated to 38.0.{0,1,2} within the last few days (38.0.0 was released on 2025-10-20, and this is being published on 2025-10-24). This likely means that almost no embedding is affected, but this security issue is nonetheless being posted for awareness.

Patches

Wasmtime 38.0.3 has been released and is patched to fix this issue.

Workarounds

References

The PR which refactored setjmp/longjmp usage and introduced this issue is bytecodealliance/wasmtime#11592.

References