Stream: git-wasmtime

Topic: wasmtime / issue #13141 Uncaught segfault with GC tunables

Wasmtime GitHub notifications bot (Apr 19 2026 at 15:47):

alexcrichton assigned fitzgen to issue #13141.

Wasmtime GitHub notifications bot (Apr 19 2026 at 15:47):

alexcrichton opened issue #13141:

Reproduction:

$ cargo run -q wast ./tests/spec_testsuite/array_fill.wast -Ogc-heap-may-move=n -Ogc-heap-reservation=0 -Wfunction-references,gc
zsh: segmentation fault  cargo run wast /Users/alex/code/wasmtime/tests/spec_testsuite/array_fill.wast

This first started with #13080, the introduction of GC heap tunables, due to the flags used. Unsure if it's a latent bug exposed by that or caused by that PR itself, but my guess is that PR itself.

Wasmtime GitHub notifications bot (Apr 19 2026 at 15:47):

alexcrichton added the wasm-proposal:gc label to Issue #13141.

Wasmtime GitHub notifications bot (Apr 19 2026 at 15:54):

alexcrichton commented on issue #13141:

Another likely culprit that's the same issue:

<details>

(module
  (type (;0;) (func (param i32)))
  (type (;1;) (func (param i32)))
  (type (;2;) (func (param i32)))
  (type (;3;) (func (param i32)))
  (type (;4;) (func (param i32)))
  (type (;5;) (func (param i32)))
  (type (;6;) (func (param i32)))
  (type (;7;) (func (param i32)))
  (type (;8;) (func (result i32)))
  (type (;9;) (func (result i32)))
  (type (;10;) (func (result i32)))
  (type (;11;) (func (result i32)))
  (type (;12;) (func (result i32)))
  (type (;13;) (func (result i32)))
  (type (;14;) (func (result i32)))
  (type (;15;) (func (result i32)))
  (type (;16;) (func (result i32)))
  (type (;17;) (func (param i32 i32)))
  (type (;18;) (func))
  (import "" "check_i32" (func (;0;) (type 17)))
  (tag (;0;) (type 0) (param i32))
  (tag (;1;) (type 1) (param i32))
  (tag (;2;) (type 2) (param i32))
  (tag (;3;) (type 3) (param i32))
  (tag (;4;) (type 4) (param i32))
  (tag (;5;) (type 5) (param i32))
  (tag (;6;) (type 6) (param i32))
  (tag (;7;) (type 7) (param i32))
  (export "run" (func 15))
  (func (;1;) (type 16) (result i32)
    call 2
  )
  (func (;2;) (type 16) (result i32)
    call 3
  )
  (func (;3;) (type 16) (result i32)
    call 4
  )
  (func (;4;) (type 16) (result i32)
    call 5
  )
  (func (;5;) (type 16) (result i32)
    call 6
  )
  (func (;6;) (type 16) (result i32)
    block (result i32) ;; label = @1
      block (type 8) (result i32) ;; label = @2
        try_table (catch 0 0 (;@2;)) ;; label = @3
          call 7
          i32.const 0
          br 2 (;@1;)
        end
        unreachable
      end
      i32.const 4096
      call 0
      i32.const 1
    end
  )
  (func (;7;) (type 18)
    i32.const 4096
    throw 0
  )
  (func (;8;) (type 16) (result i32)
    call 9
  )
  (func (;9;) (type 16) (result i32)
    call 10
  )
  (func (;10;) (type 16) (result i32)
    call 11
  )
  (func (;11;) (type 16) (result i32)
    call 12
  )
  (func (;12;) (type 16) (result i32)
    call 13
  )
  (func (;13;) (type 16) (result i32)
    block (result i32) ;; label = @1
      block (type 8) (result i32) ;; label = @2
        try_table (catch 0 0 (;@2;)) ;; label = @3
          call 14
          i32.const 0
          br 2 (;@1;)
        end
        unreachable
      end
      i32.const 4096
      call 0
      i32.const 1
    end
  )
  (func (;14;) (type 18)
    i32.const 4096
    throw 0
  )
  (func (;15;) (type 16) (result i32)
    (local i32)
    call 1
    local.get 0
    i32.add
    local.set 0
    call 8
    local.get 0
    i32.add
    local.set 0
    local.get 0
  )
)

</details>

$ cargo run -- --invoke run -Wunknown-imports-default -Ccollector=null -Ogc-heap-may-move=n -Ogc-heap-reservation=32 -Wexceptions testcase1.wat
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
     Running `target/debug/wasmtime --invoke run -Wunknown-imports-default -Ccollector=null -Ogc-heap-may-move=n -Ogc-heap-reservation=32 -Wexceptions testcase1.wat`
zsh: segmentation fault  cargo run -- --invoke run -Wunknown-imports-default -Ccollector=null

Wasmtime GitHub notifications bot (Apr 19 2026 at 15:57):

alexcrichton commented on issue #13141:

Another likely culprit in the gc_ops fuzzer as of https://github.com/bytecodealliance/wasmtime/commit/495df131b40d81f76f41e6fcf2a157dedad3477b (not easily reproducible in the CLI)

gc_ops.txt

Wasmtime GitHub notifications bot (Apr 19 2026 at 15:59):

alexcrichton commented on issue #13141:

Another segfaulting wast:

$ cargo run wast ./tests/spec_testsuite/array.wast -Ogc-heap-may-move=n -Ogc-heap-reservation=1024 -Wfunction-references,gc
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.16s
     Running `target/debug/wasmtime wast ./tests/spec_testsuite/array.wast -Ogc-heap-may-move=n -Ogc-heap-reservation=1024 -Wfunction-references,gc`
zsh: segmentation fault  cargo run wast ./tests/spec_testsuite/array.wast -Ogc-heap-may-move=n

Wasmtime GitHub notifications bot (Apr 20 2026 at 12:24):

fitzgen commented on issue #13141:

Thanks will look into this shortly

Wasmtime GitHub notifications bot (Apr 20 2026 at 14:29):

alexcrichton commented on issue #13141:

Also ilkely related, but a SIGILL rather than a SIGSEGV:

$ cargo run wast ./tests/spec_testsuite/array_fill.wast -Ccollector=null -Ccranelift-enable_heap_access_spectre_mitigation=false -Ogc-heap-may-move=n -Ogc-heap-reservation=0 -Wfunction-references,gc
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.11s
     Running `target/debug/wasmtime wast ./tests/spec_testsuite/array_fill.wast -Ccollector=null -Ccranelift-enable_heap_access_spectre_mitigation=false -Ogc-heap-may-move=n -Ogc-heap-reservation=0 -Wfunction-references,gc`
zsh: illegal hardware instruction (core dumped)  cargo run wast ./tests/spec_testsuite/array_fill.wast -Ccollector=null

Wasmtime GitHub notifications bot (Apr 20 2026 at 17:03):

alexcrichton added the fuzz-bug label to Issue #13141.

Wasmtime GitHub notifications bot (Apr 21 2026 at 20:07):

alexcrichton closed issue #13141:

Reproduction:

$ cargo run -q wast ./tests/spec_testsuite/array_fill.wast -Ogc-heap-may-move=n -Ogc-heap-reservation=0 -Wfunction-references,gc
zsh: segmentation fault  cargo run wast /Users/alex/code/wasmtime/tests/spec_testsuite/array_fill.wast

This first started with #13080, the introduction of GC heap tunables, due to the flags used. Unsure if it's a latent bug exposed by that or caused by that PR itself, but my guess is that PR itself.

Wasmtime GitHub notifications bot (Apr 28 2026 at 07:24):

Josef-Reichardt commented on issue #13141:

If I understand it correctly this will fix sonatype-2026-002709 (High CVSS Score: 7.7), right?

Any chance to get a patch release soon?

Wasmtime GitHub notifications bot (Apr 28 2026 at 09:40):

tschneidereit commented on issue #13141:

@Josef-Reichardt it looks like that Sonatype CVE is about this issue, yes. However, this is not an issue the Wasmtime project would assign a CVE to; you can tell because we haven't :) The reason is that GC support isn't yet production-ready, so even if we were to publish a patch release with this fix in, we'd still strongly advise against enabling GC support in environments where you run untrusted code of any kind.

As an aside, Sonatype are doing all involved a massive disservice in publishing CVEs like this: it looks like they create CVEs for issues found by OSS-Fuzz if they look security related, regardless of whether they'd be reachable in supported configurations of the project. Additionally, at least in this case the "Components Impacted" tab is also absolutely entirely wrong: GC support didn't exist in any way in the vast majority of releases they state are affected.

Based on this, I would strongly recommend treating Sonartype as an unreliable source of information for vulnerabilities, lest you want to drown in noise.

Wasmtime GitHub notifications bot (Apr 28 2026 at 09:47):

tschneidereit edited a comment on issue #13141:

@Josef-Reichardt it looks like that Sonatype CVE is about this issue, yes. However, this is not an issue the Wasmtime project would assign a CVE to; you can tell because we haven't :) The reason is that GC support isn't yet production-ready, so even if we were to publish a patch release with this fix in, we'd still strongly advise against enabling GC support in environments where you run untrusted code of any kind.

As an aside, Sonatype are doing all involved a massive disservice in publishing CVEs like this: it looks like they create CVEs for issues found by OSS-Fuzz if they look security related, regardless of whether they'd be reachable in supported configurations of the project. Additionally, at least in this case the "Components Impacted" tab is also absolutely entirely wrong: GC support didn't exist in any way in the vast majority of releases they state are affected.

Based on this, I would strongly recommend treating Sonatype as an unreliable source of information for vulnerabilities, lest you want to drown in noise.

Last updated: May 03 2026 at 22:13 UTC