wasmtime / issue #10397 [GC] id from different slab · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #10397 [GC] id from different slab

Wasmtime GitHub notifications bot (Mar 14 2025 at 11:31):

vouillon added the bug label to Issue #10397.

Wasmtime GitHub notifications bot (Mar 14 2025 at 11:31):

Test Case

slab-mismatch.zip

Steps to Reproduce

Run the following command:
./target/debug/wasmtime  -W=all-proposals=y slab-mismatch.wasm
Expected Results

It should not crash.

Actual Results

We get a panic:
thread 'main' panicked at /home/jerome/sources/wasmtime/crates/slab/src/lib.rs:387:14:
id from different slab
Versions and Environment

Wasmtime commit: a3381e48775912a3e1a68c05180932f3ce74c5b4

Operating system: Linux

Architecture: x64

Wasmtime GitHub notifications bot (Mar 17 2025 at 15:56):

fitzgen commented on issue #10397:

Thanks for filing this bug!

Wasmtime GitHub notifications bot (Mar 18 2025 at 17:40):

fitzgen commented on issue #10397:

Minimized a bit further:

(module
  (type $func (func))
  (type $array (array (mut i32)))
  (type $struct (sub (struct (field $field (ref $func)))))

  (elem func $nop)
  (func $nop)

  (func (export "")
    (local $local_array (ref $array))
    (local $local_struct (ref $struct))
    (local.set $local_struct (struct.new $struct (ref.func $nop)))
    (loop $outer
      (local.set $local_array (array.new $array (i32.const 0) (i32.const 1)))
      (loop $inner
        (array.set $array (ref.cast (ref $array) (local.get $local_array))
                          (i32.const 0)
                          (i32.const 1))
        (br_if $inner (i32.const 0))
      )
      (call_ref $func (struct.get $struct $field (local.get $local_struct)))
      (br $outer)
    )
  )
)

There are a couple interesting things that can't be removed from the test case while preserving the crash:

the br_if whose operand is a constant 0
the ref.cast into the exact same type that it already is

Wasmtime GitHub notifications bot (Mar 21 2025 at 21:31):

fitzgen commented on issue #10397:

I have a fix for this over in https://github.com/bytecodealliance/wasmtime/pull/10456

Thanks again for the bug report!

Wasmtime GitHub notifications bot (Mar 21 2025 at 22:00):

vouillon commented on issue #10397:

Thanks a lot!
I'm not sure the fix is complete, though. I still get similar errors (id from different slab and assertion failed: types.is_subtype(actual_ty, expected_ty)). I'll try to find the time to produce a reduced test case.

Wasmtime GitHub notifications bot (Mar 21 2025 at 22:13):

fitzgen commented on issue #10397:

Yeah, we sandbox the GC heap, so when we have any kind of GC heap corruption bug, it tends to look like those panics rather than overwriting host memory or what have you. Occasionally it might look like a SIGILL at a ud2 instruction because of an assertion check inside of JIT code tripping. But the important thing is that corruption in the GC heap should never result in memory unsafety in the rest of the runtime, just panics or whatever.

Anyways, the point is, it is likely not the same bug if it still triggers after https://github.com/bytecodealliance/wasmtime/pull/10456, but just that all kinds of GC heap corruption tend to show the same symptoms.

But as always, reduced test cases are super helpful, thanks for taking the time to make reproducers and all that!

Wasmtime GitHub notifications bot (Mar 24 2025 at 18:37):

cfallin closed issue #10397:

Test Case

slab-mismatch.zip

Steps to Reproduce

Run the following command:
./target/debug/wasmtime  -W=all-proposals=y slab-mismatch.wasm
Expected Results

It should not crash.

Actual Results

We get a panic:
thread 'main' panicked at /home/jerome/sources/wasmtime/crates/slab/src/lib.rs:387:14:
id from different slab
Versions and Environment

Wasmtime commit: a3381e48775912a3e1a68c05180932f3ce74c5b4

Operating system: Linux

Architecture: x64

Last updated: Apr 17 2025 at 18:04 UTC