Stream: git-wasmtime

Topic: wasmtime / issue #12401 <target> fuzzbug: [cranelift] pan...

Wasmtime GitHub notifications bot (Jan 23 2026 at 06:28):

weijinjinnihao added the bug label to Issue #12401.

Wasmtime GitHub notifications bot (Jan 23 2026 at 06:28):

weijinjinnihao opened issue #12401:

Bug Report

Describe the Bug

Executing a spec-conformant WebAssembly module (file134.wasm) in Wasmtime v40.0.0 consistently triggers a panic in the Cranelift backend during compilation.

The module passes wasm-tools validate without any errors, but Wasmtime aborts with an internal unimplemented for > 64 bits panic during the optimization phase, leading to immediate process termination.

This crash does not occur in other WebAssembly engines (Wasmer, WasmEdge, WAMR), suggesting an engine-specific bug in Wasmtime/Cranelift.

The issue represents a compiler crash on valid input and can be exploited to cause denial-of-service in Wasmtime-based deployments.

Key Insight from Dump File

• We provide an attached disassembly dump (file134.dump) generated by wasm-tools for detailed inspection.

• Based on the dump file, we verified that:

  • All memory accesses are within declared bounds.
  • All data segments are placed within the allocated linear memory.
  • No obvious out-of-bounds memory or malformed section layout is present.

• Despite the absence of memory or data section violations, the dump reveals instruction patterns that still trigger an internal Cranelift optimization path leading to the panic:
  unimplemented for > 64 bits

• This indicates that the crash is not caused by malformed memory layout or invalid data segments, but by an unhandled or missing implementation path in Cranelift’s optimization pipeline, likely related to wide integer or SIMD-related lowering.

• Differential testing further confirms this as an engine-specific issue:

• wasmtime: :cross_mark: panic
• wasmer: :check: runs without crash
• wasmedge: :check: runs without crash
• wamr: :check: runs without crash

This strongly suggests a compiler bug in Wasmtime/Cranelift triggered by a valid instruction pattern, rather than by out-of-bounds memory, malformed sections, or undefined behavior in the input module.

To Reproduce

wasmtime-v40.0.0-x86_64-linux/wasmtime run ./file134.wasm --invoke main

• This issue was not discovered via cargo fuzz.

Desktop Environment

• OS and Version: Linux (Ubuntu 24.04.2 LTS)
• Wasmtime Version and Source:
  https://github.com/bytecodealliance/wasmtime/releases/download/v40.0.0/wasmtime-v40.0.0-x86_64-linux.tar.xz

Stack trace or other relevant details

thread '<unnamed>' (1307851) panicked at cranelift/codegen/src/opts.rs:191:5:
unimplemented for > 64 bits
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::option::expect_failed
   3: cranelift_codegen::opts::generated_code::constructor_iconst_u
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Aborted (core dumped)

wasmtime_panic_file134.zip

Wasmtime GitHub notifications bot (Jan 23 2026 at 06:28):

weijinjinnihao added the fuzz-bug label to Issue #12401.

Wasmtime GitHub notifications bot (Jan 23 2026 at 09:08):

tschneidereit closed issue #12401:

Bug Report

Describe the Bug

Executing a spec-conformant WebAssembly module (file134.wasm) in Wasmtime v40.0.0 consistently triggers a panic in the Cranelift backend during compilation.

The module passes wasm-tools validate without any errors, but Wasmtime aborts with an internal unimplemented for > 64 bits panic during the optimization phase, leading to immediate process termination.

This crash does not occur in other WebAssembly engines (Wasmer, WasmEdge, WAMR), suggesting an engine-specific bug in Wasmtime/Cranelift.

The issue represents a compiler crash on valid input and can be exploited to cause denial-of-service in Wasmtime-based deployments.

Key Insight from Dump File

• We provide an attached disassembly dump (file134.dump) generated by wasm-tools for detailed inspection.

• Based on the dump file, we verified that:

  • All memory accesses are within declared bounds.
  • All data segments are placed within the allocated linear memory.
  • No obvious out-of-bounds memory or malformed section layout is present.

• Despite the absence of memory or data section violations, the dump reveals instruction patterns that still trigger an internal Cranelift optimization path leading to the panic:
  unimplemented for > 64 bits

• This indicates that the crash is not caused by malformed memory layout or invalid data segments, but by an unhandled or missing implementation path in Cranelift’s optimization pipeline, likely related to wide integer or SIMD-related lowering.

• Differential testing further confirms this as an engine-specific issue:

• wasmtime: :cross_mark: panic
• wasmer: :check: runs without crash
• wasmedge: :check: runs without crash
• wamr: :check: runs without crash

This strongly suggests a compiler bug in Wasmtime/Cranelift triggered by a valid instruction pattern, rather than by out-of-bounds memory, malformed sections, or undefined behavior in the input module.

To Reproduce

wasmtime-v40.0.0-x86_64-linux/wasmtime run ./file134.wasm --invoke main

• This issue was not discovered via cargo fuzz.

Desktop Environment

• OS and Version: Linux (Ubuntu 24.04.2 LTS)
• Wasmtime Version and Source:
  https://github.com/bytecodealliance/wasmtime/releases/download/v40.0.0/wasmtime-v40.0.0-x86_64-linux.tar.xz

Stack trace or other relevant details

thread '<unnamed>' (1307851) panicked at cranelift/codegen/src/opts.rs:191:5:
unimplemented for > 64 bits
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::option::expect_failed
   3: cranelift_codegen::opts::generated_code::constructor_iconst_u
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Aborted (core dumped)

wasmtime_panic_file134.zip

Wasmtime GitHub notifications bot (Jan 23 2026 at 09:08):

tschneidereit commented on issue #12401:

This is a duplicate of #12170, and I confirmed that it reproduces in v40.0.0 and is fixed in v40.0.2 and onward.

On a related note, it's clear that you used an LLM to generate this report. We don't have any rules against doing so, and appreciate reports of real issues. This clearly is a real issue, but it has was fixed before the report. Please ensure that, however exactly you discover issues, you always check whether the issue reproduces with the latest supported releases.

Wasmtime GitHub notifications bot (Jan 23 2026 at 11:20):

weijinjinnihao commented on issue #12401:

Ok, thank you for your response.

Last updated: Jan 29 2026 at 13:25 UTC