Stream: git-wasmtime

Topic: wasmtime / issue #13409 Cranelift: Potential soundness is...

Wasmtime GitHub notifications bot (May 19 2026 at 13:34):

varies-rust opened issue #13409:

Hello, and thank you for maintaining this crate.

I found a sanitizer/Miri failure reachable through public crate APIs using safe Rust code. I may be missing crate-specific preconditions, but the behavior looks worth checking because safe callers should not be able to trigger undefined behavior.

Summary

• Crate: cranelift-egraph
• Version tested: 0.91.1
• API paths with similar failures observed:
  • BumpVec::push
  • BumpVec::reserve
  • BumpVec::truncate
  • BumpArena::single
  • BumpArena::vec_with_capacity

Observed diagnostics

MemorySanitizer use of uninitialized value: WARNING: MemorySanitizer: use-of-uninitialized-value
Miri undefined behavior: error: Undefined Behavior: reading memory at alloc68512[0x0..0x8], but memory is uninitialized at [0x0..0x8], and this operation requires initialized memory

Reproduction

The snippets below are minimal readable reproducers. Each PoC also includes the source location most relevant to the reported failure.

PoC 1: test_cranelift_egraph109::generated_test_109

Relevant source location:

• src/bumpvec.rs:357: BumpVec::push accepts an arbitrary BumpArena<T> argument.
• src/bumpvec.rs:304: as_slice reads from the supplied arena using only stored base and len.

Readable equivalent PoC:

use std::io::Sink;

#[test]
fn poc() {
    let mut vec = cranelift_egraph::BumpVec::<&Sink>::default();
    let mut arena_b = cranelift_egraph::BumpArena::<&Sink>::default();
    let sink = std::io::sink();

    vec.push(&sink, &mut arena_b);

    let mut arena_a = cranelift_egraph::BumpArena::<&Sink>::default();
    let _ = arena_a.vec_with_capacity(1);
    let _ = vec.as_slice(&arena_a)[0];
}

Observed diagnostic:

WARNING: MemorySanitizer: use-of-uninitialized-value

PoC 2: test_cranelift_egraph120::generated_test_120

Relevant source location:

• src/bumpvec.rs:334: reserve also accepts an arbitrary arena argument.
• src/bumpvec.rs:357: push can attach data through a different arena than later operations use.

Readable equivalent PoC:

use std::io::Sink;

#[test]
fn poc() {
    let mut vec = cranelift_egraph::BumpVec::<&Sink>::default();
    let mut arena_b = cranelift_egraph::BumpArena::<&Sink>::default();
    let sink = std::io::sink();

    vec.push(&sink, &mut arena_b);

    let mut arena_a = cranelift_egraph::BumpArena::<&Sink>::default();
    let _ = arena_a.vec_with_capacity(2);
    vec.reserve(1, &mut arena_a);
}

Observed diagnostic:

error: Undefined Behavior: reading memory at alloc68512[0x0..0x8], but memory is uninitialized at [0x0..0x8], and this operation requires initialized memory

Source review and suggested fix

Brief reasoning:

• BumpVec tracks only numeric indices, not the arena that actually owns the backing slots.
• A safe caller can push into one arena and later read or reallocate the same logical vector through another arena.
• That breaks the storage provenance the unsafe helpers rely on.

Suggested fix:

• Tie the vector to the arena lifetime or store and check arena identity before using arena-backed storage.

Thanks again for taking a look.

Wasmtime GitHub notifications bot (May 19 2026 at 13:35):

varies-rust added the bug label to Issue #13409.

Wasmtime GitHub notifications bot (May 19 2026 at 13:35):

varies-rust added the cranelift label to Issue #13409.

Wasmtime GitHub notifications bot (May 19 2026 at 17:49):

cfallin commented on issue #13409:

Hi: cranelift-egraph is no longer maintained -- we merged the egraph implementation back into our existing cranelift-codegen crate long ago. The old crate version still on crates.io is an artifact of our project setup with multiple crates: when we delete a crate, we no longer publish new versions with new Cranelift/Wasmtime releases, so an old version remains forever on crates.io.

Maybe we should change that (e.g. publish a "tombstone" version that is empty, or yank the crate). @fitzgen @alexcrichton what do you think?

Wasmtime GitHub notifications bot (May 19 2026 at 19:25):

fitzgen commented on issue #13409:

Either seems fine by me. Also doing nothing is probably also fine, since this is the first spurious report we've had in many years of that crate not being active.

Wasmtime GitHub notifications bot (May 19 2026 at 21:59):

alexcrichton commented on issue #13409:

Personally I'd say we do nothing here, there's a fair number of wasmtime-* crates that are no longer maintained and I don't know the set that we'd have to go back and publish markers for.

Wasmtime GitHub notifications bot (May 19 2026 at 22:04):

cfallin closed issue #13409:

Hello, and thank you for maintaining this crate.

I found a sanitizer/Miri failure reachable through public crate APIs using safe Rust code. I may be missing crate-specific preconditions, but the behavior looks worth checking because safe callers should not be able to trigger undefined behavior.

Summary

• Crate: cranelift-egraph
• Version tested: 0.91.1
• API paths with similar failures observed:
  • BumpVec::push
  • BumpVec::reserve
  • BumpVec::truncate
  • BumpArena::single
  • BumpArena::vec_with_capacity

Observed diagnostics

MemorySanitizer use of uninitialized value: WARNING: MemorySanitizer: use-of-uninitialized-value
Miri undefined behavior: error: Undefined Behavior: reading memory at alloc68512[0x0..0x8], but memory is uninitialized at [0x0..0x8], and this operation requires initialized memory

Reproduction

The snippets below are minimal readable reproducers. Each PoC also includes the source location most relevant to the reported failure.

PoC 1: test_cranelift_egraph109::generated_test_109

Relevant source location:

• src/bumpvec.rs:357: BumpVec::push accepts an arbitrary BumpArena<T> argument.
• src/bumpvec.rs:304: as_slice reads from the supplied arena using only stored base and len.

Readable equivalent PoC:

use std::io::Sink;

#[test]
fn poc() {
    let mut vec = cranelift_egraph::BumpVec::<&Sink>::default();
    let mut arena_b = cranelift_egraph::BumpArena::<&Sink>::default();
    let sink = std::io::sink();

    vec.push(&sink, &mut arena_b);

    let mut arena_a = cranelift_egraph::BumpArena::<&Sink>::default();
    let _ = arena_a.vec_with_capacity(1);
    let _ = vec.as_slice(&arena_a)[0];
}

Observed diagnostic:

WARNING: MemorySanitizer: use-of-uninitialized-value

PoC 2: test_cranelift_egraph120::generated_test_120

Relevant source location:

• src/bumpvec.rs:334: reserve also accepts an arbitrary arena argument.
• src/bumpvec.rs:357: push can attach data through a different arena than later operations use.

Readable equivalent PoC:

use std::io::Sink;

#[test]
fn poc() {
    let mut vec = cranelift_egraph::BumpVec::<&Sink>::default();
    let mut arena_b = cranelift_egraph::BumpArena::<&Sink>::default();
    let sink = std::io::sink();

    vec.push(&sink, &mut arena_b);

    let mut arena_a = cranelift_egraph::BumpArena::<&Sink>::default();
    let _ = arena_a.vec_with_capacity(2);
    vec.reserve(1, &mut arena_a);
}

Observed diagnostic:

error: Undefined Behavior: reading memory at alloc68512[0x0..0x8], but memory is uninitialized at [0x0..0x8], and this operation requires initialized memory

Source review and suggested fix

Brief reasoning:

• BumpVec tracks only numeric indices, not the arena that actually owns the backing slots.
• A safe caller can push into one arena and later read or reallocate the same logical vector through another arena.
• That breaks the storage provenance the unsafe helpers rely on.

Suggested fix:

• Tie the vector to the arena lifetime or store and check arena identity before using arena-backed storage.

Thanks again for taking a look.

Wasmtime GitHub notifications bot (May 19 2026 at 22:04):

cfallin commented on issue #13409:

Cool, I will close the issue then, on the basis that the version of Wasmtime+Cranelift that that crate is associated with is far outside of our current support window. Thanks nevertheless for filing the issue!

Last updated: Jun 01 2026 at 09:49 UTC