Stream: git-wasmtime

Topic: wasmtime / issue #14161 wast_tests fuzzbug: OOB bulk oper...


view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2026 at 18:01):

adamrk opened issue #14161:

OSS fuzz failure: https://oss-fuzz.com/testcase-detail/4690035493109760

The following wast fails with fuel set to 18446744073709551615:

(module
  (memory i64 1)
  (func (export "fill64") (param $dst i64) (param $len i64)
    local.get $dst
    i32.const 0
    local.get $len
    memory.fill))

;; Drains fuel to ~0 but still traps out-of-bounds correctly -> this passes.
(assert_trap (invoke "fill64" (i64.const 0) (i64.const -1)) "out of bounds")
;; No fuel left: traps "all fuel consumed" instead of "out of bounds" -> FAILS.
(assert_trap (invoke "fill64" (i64.const 0) (i64.const -1)) "out of bounds")

Run it with cargo run -- wast -Wfuel=18446744073709551615 memory_fill.reduced.wast:

$ cargo run -- wast -Wfuel=18446744073709551615 memory_fill.reduced.wast
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s
     Running `target/debug/wasmtime wast -Wfuel=18446744073709551615 memory_fill.reduced.wast`
Error: failed to run script file 'memory_fill.reduced.wast'

Caused by:
    0: failed directive on memory_fill.reduced.wast:35
    1: expected 'out of bounds', got 'error while executing at wasm backtrace:
    0:     0x30 - wasm-function[0]
                    at ./memory_fill.reduced.wast:30:5

Caused by:
    wasm trap: all fuel consumed by WebAssembly
'

This is the same as the issue described by @alexcrichton here: https://github.com/bytecodealliance/wasmtime/issues/14047#issuecomment-5297814096

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2026 at 18:01):

adamrk added the bug label to Issue #14161.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2026 at 18:01):

adamrk added the fuzz-bug label to Issue #14161.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2026 at 18:58):

adamrk commented on issue #14161:

How about doing the charge afterward based on both the bulk operation size and the return value? So the fuel charge would be determined at runtime even if the size is const, but we could keep the existing logic for "small" const sizes.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2026 at 19:14):

alexcrichton commented on issue #14161:

That sounds like a great idea to me! It's pretty arbitrary to check either before or after so I think it's basically equivalent

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2026 at 19:23):

adamrk commented on issue #14161:

Or maybe even consuming within the libcall is better since we'd need to do that anyway to handle https://github.com/bytecodealliance/wasmtime/issues/14047#issuecomment-5297814096 . For now we could just consume the fuel in the libcall and let cranelift generated code decide if it wants to check for fuel/epoch after the call resolves.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 19 2026 at 19:31):

alexcrichton commented on issue #14161:

Consuming fuel I think would be easy enough, but actually injecting a yield point for epochs and/or refueling situations I think may be relatively difficult, and for that I suspect it'll be easiest/best to leave it to the compiled code to figure out

view this post on Zulip Wasmtime GitHub notifications bot (Aug 25 2026 at 18:07):

alexcrichton added the wasmtime:fuel label to Issue #14161.


Last updated: Aug 30 2026 at 09:07 UTC