Stream: git-wasmtime

Topic: wasmtime / issue #12905 Soundness issue with `StringPool`...

Wasmtime GitHub notifications bot (Mar 31 2026 at 12:52):

flavio opened issue #12905:

After upgrading from wasmtime 42.0 to 43.0, some of my unit tests started failing.

My code was:

• Defining a Linker
• Defining some host functions on the linker
• Cloning the linker
• Storing the cloned linker for future reuse
• Dropping the original linker

The cloned linker was not capable of producing an Instance, because it wasn't capable of resolving the imported functions.

Test Case

No special Wasm file needed to reproduce the issue

Steps to Reproduce

I've created a reproducer here.

Checkout the code and run:

make run-v42

The code will work as expected.

Then run:

make run-v43

The linker bug will cause the program to error.

Expected Results

Cloning a Linker, and reusing it at a future point in time should not lead to runtime errors.

Actual Results

The creation of an Instance fails with an error. The error complains about the linker
not being able to resolve the used importes.

Versions and Environment

Wasmtime version or commit: >= 43.0.0

Operating system: Linux

Architecture: x86_64

Extra Info

I've used AI during the debugging process. I've a good knowledge of wasmtime internal, ofc not like any of the maintainers :sweat_smile: . I think the root cause is correct, there's no AI allucination.

I've also produced a fix for that (PR to come).

Wasmtime GitHub notifications bot (Mar 31 2026 at 12:52):

flavio added the bug label to Issue #12905.

Wasmtime GitHub notifications bot (Mar 31 2026 at 12:55):

flavio edited issue #12905:

After upgrading from wasmtime 42.0 to 43.0, some of my unit tests started failing.

My code was:

• Defining a Linker
• Defining some host functions on the linker
• Cloning the linker
• Storing the cloned linker for future reuse
• Dropping the original linker

The cloned linker was not capable of producing an Instance, because it wasn't capable of resolving the imported functions.

Test Case

No special Wasm file needed to reproduce the issue

Steps to Reproduce

I've created a reproducer here.

Checkout the code and run:

make run-v42

The code will work as expected.

Then run:

make run-v43

The linker bug will cause the program to error.

Expected Results

Cloning a Linker, and reusing it at a future point in time should not lead to runtime errors.

Actual Results

The creation of an Instance fails with an error. The error complains about the linker
not being able to resolve the used importes.

Versions and Environment

Wasmtime version or commit: >= 43.0.0

Operating system: Linux

Architecture: x86_64

Extra Info

I've used AI during the debugging process. I've a good knowledge of wasmtime internal, ofc not like any of the maintainers :sweat_smile: . I think the root cause is correct, there's no AI allucination.

I've also produced a fix for that (PR to come).

Update: PR

Wasmtime GitHub notifications bot (Apr 09 2026 at 19:26):

alexcrichton closed issue #12905:

After upgrading from wasmtime 42.0 to 43.0, some of my unit tests started failing.

My code was:

• Defining a Linker
• Defining some host functions on the linker
• Cloning the linker
• Storing the cloned linker for future reuse
• Dropping the original linker

The cloned linker was not capable of producing an Instance, because it wasn't capable of resolving the imported functions.

Test Case

No special Wasm file needed to reproduce the issue

Steps to Reproduce

I've created a reproducer here.

Checkout the code and run:

make run-v42

The code will work as expected.

Then run:

make run-v43

The linker bug will cause the program to error.

Expected Results

Cloning a Linker, and reusing it at a future point in time should not lead to runtime errors.

Actual Results

The creation of an Instance fails with an error. The error complains about the linker
not being able to resolve the used importes.

Versions and Environment

Wasmtime version or commit: >= 43.0.0

Operating system: Linux

Architecture: x86_64

Extra Info

I've used AI during the debugging process. I've a good knowledge of wasmtime internal, ofc not like any of the maintainers :sweat_smile: . I think the root cause is correct, there's no AI allucination.

I've also produced a fix for that (PR to come).

Update: PR

Wasmtime GitHub notifications bot (Apr 09 2026 at 19:26):

alexcrichton commented on issue #12905:

Fixed in https://github.com/bytecodealliance/wasmtime/pull/12906

Last updated: Apr 13 2026 at 00:25 UTC