[LOW] Security Advisory: Wasmtime has data leakage between pooling allocator instances (wasmtime, wasmtime, wasmtime)

Wasmtime’s pooling allocator leaks data between WebAssembly instances in narrow configurations. Attackers could read sensitive data from prior guests if you enable pooling with zero guard size, memory reservations under 4GiB, and matching max sizes. Patched versions—36.0.7, 42.0.2, and 43.0.1—fix it. Update now if you match those settings.

The bug stems from mismatched predicates in Wasmtime’s memory management. Compile-time checks assume virtual memory permissions reset safely on reuse. Runtime code skips resets due to the wrong condition, leaving old mappings intact. Out-of-bounds loads that should segfault instead read prior instance data. This shatters WebAssembly’s memory isolation and Wasmtime’s sandbox promises.

Trigger Conditions

Four settings must align for exposure:

• Pooling allocator active.
• Config::memory_guard_size set to 0—no guard pages.
• Config::memory_reservation below 4GiB (4,294,967,296 bytes).
• Pooling max_memory_size equals memory_reservation.

Defaults dodge this: Wasmtime ships with guard pages and safe reservations. But embeddings—like custom servers or tools—often tweak for performance. Pooling reuses virtual mappings to cut allocation overhead in high-throughput WASM workloads. Skip guard pages to squeeze more efficiency, and you risk leaks.

Wasmtime powers secure WASM execution in Deno, Cloudflare Workers edges, and serverless runtimes. It traps faults via signals or hardware virtualization. This flaw undermines that: one tenant’s heap becomes another’s playground. Imagine multi-tenant services; customer A writes keys, customer B reads them post-reuse.

Fixes and Mitigations

Upgrade immediately. Wasmtime 36.0.7 patches the 36.x branch, 42.0.2 fixes 42.x, and 43.0.1 covers the latest. No zero-days here—disclosure was responsible via GitHub.

Workarounds block any condition:

• Enable guard pages: set memory_guard_size to 64KiB or higher. Traps bleed attempts reliably.
• Bump memory_reservation to 4GiB+. Aligns runtime/compile predicates.
• Mismatch max_memory_size and reservation in pooling config.
• Disable pooling outright—use fresh allocs per instance.

Guard pages stand out: they add 64KB per memory but enforce hard bounds. Cost scales with instance count, but beats leaks.

Verify via code. Example config triggering vuln:

let config = Config::new();
config.memory_guard_size(0);
config.memory_reservation(2 * 1024 * 1024 * 1024); // 2GiB
let pool = PoolingAllocationConfig::new()
    .max_memory_size(config.memory_reservation().unwrap());

Safe tweak:

config.memory_guard_size(64 * 1024); // 64KiB guards

Broader Implications

This exposes Wasmtime’s config complexity. Defaults shield casual users, but power users chase perf and trip wires. WASM sandboxes rely on OS protections—mprotect, sigsegv, or VMMs like wasmtime-vmol. One predicate flip erodes that trust.

Check embeddings: Bytecode Alliance tools, wasmer alternatives, or Kubernetes WASM sidecars. Audit configs against these four flags. No evidence of exploits, but CVEs loom for history.

Why care? WASM grows in confidential computing, serverless, and browsers. Leaks kill isolation. Developers: audit now, prioritize patches. Runtimes must dogfood defaults harder. Fair play to Wasmtime team—quick fix, clear advisory. But it reminds: perf hacks demand scrutiny.

Scan logs for pooling use. Test with crafted WASM: write to high offsets in guest A, load in guest B. If data crosses, you’re hit. Stay vigilant; sandboxes aren’t set-it-forget-it.