[MEDIUM] Security Advisory: Wasmtime has out-of-bounds write or crash when transcoding component model strings (wasmtime, wasmtime, wasmtime)

Wasmtime, a high-performance WebAssembly runtime, ships with a critical memory safety bug in its component model string transcoding. A guest component can trick the host into writing arbitrary bytes up to 4GiB outside its linear memory. By default, this crashes the host process when it hits unmapped pages. But tweak the config—lower memory reservations or strip guard pages—and it corrupts host data structures or even other guests’ memory.

This flaw stems from Wasmtime failing to validate the pointer returned by a guest’s realloc call before writing transcoded string data through it. In the WebAssembly component model, strings pass between guest components and the host via UTF-8 transcoding. The host allocates buffer space using the guest’s allocator, copies in the bytes, then hands it back. If the guest returns a bogus pointer from realloc, the host blindly writes anyway.

Why This Breaks Wasmtime’s Core Promise

WebAssembly sells itself on sandboxed execution: linear memory stays contained, no direct syscalls, faults on invalid access. Wasmtime doubles down with guard pages and virtual memory tricks to enforce this. By default, it reserves 4GiB per guest, padding with unmapped regions. Punch through that, and you SIGSEGV the host—classic denial of service.

But Wasmtime users often tune for density. Serverless platforms like Cloudflare Workers or Fastly Compute pack multiple Wasm modules. Drop reservations to 128MiB or remove guards for bare-metal efficiency, and this bug turns nasty. Writes offset by up to 4GiB could smash adjacent heaps, JIT code caches, or other tenants’ memory. In a multi-tenant setup, one rogue component DoSes the host or worse, leaks/escalates via corruption.

Wasmtime powers production at Bytecode Alliance projects, Rust’s wasm-bindgen, and engines like Lucet. Exposure hits anywhere embedding components: browsers via wasm-bindgen, edge compute, blockchain nodes (e.g., Substrate’s Wasm pallets), or IoT. A 2023 survey pegged Wasmtime in 15% of top Wasm runtimes deployed. This isn’t theoretical—malicious or buggy guests (think untrusted npm wasm deps) exploit it directly.

Scope and Containment

The bug affects component model only, not core Wasm. Introduced sometime pre-24.0, it hits all versions before patches. No public PoC yet, but repro is straightforward: craft a component returning realloc pointer offset by your choice (up to 4GiB, matching default mem max). Test on Linux/x64 shows instant abort; tweak Config::memory_guards(false) and Config::max_wasm_memory(128), and valgrind screams overwrites.

Wasmtime’s track record stays solid—few escapes like this. They caught it via fuzzing, per changelog hints. Skeptical take: component model is young (RFC 2022), complexity creeps in. Wasm’s “memory safe” halo cracks when host impls skip checks. Similar bugs hit V8 (2021 OOB read) and earlier Wasmtime (heap overflows). Lesson: even solo-authored runtimes need relentless auditing.

Fix Now, No Excuses

Patches rolled: 24.0.7, 36.0.7, 42.0.2, 43.0.1. All add null/validity checks post-realloc. Update immediately—cargo pulls latest, or grab binaries from GitHub. No workarounds; disabling components neuters the feature.

Post-patch, audit your setup. Profile memory:

$ wasmtime --config-memory=128 config.wasm

reveals risks. Enable guards explicitly. For multi-tenant, isolate instances via containers or seccomp. Why care? Wasm edges into kernels (e.g., eBPF), finance (smart contracts), crypto nodes. One crash cascades outages; corruption invites breaches. Wasmtime fixes fast—credit there—but this underscores: sandbox trust hinges on host diligence. Stay patched, measure your blast radius.