CVE-2022-31146

Impact

There is a bug in Wasmtime’s code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection (GC). This means that if a GC happens at runtime then the collector will mistakenly think some Wasm stack frames do not have live references to garbage collected values and therefore reclaim and deallocate them. The function can then subsequently continue to use the values, leading later to use-after-free bugs.

To trigger this bug a Wasmtime host must pass a non-null externref value to a WebAssembly module and then a GC must be triggered while active Wasm frames are on the stack (either via sufficient externref activity in the Wasm or an explicit request for GC from the host). If the function has the right code shape to trigger this bug then it will be missing required stack maps used to inform the garbage collector of live references within the stack frame. The precise shape of function necessary to have a missing stack map is somewhat nuanced, but one example is that on x86_64 functions using table.get or table.set may have the conditions necessary to omit some stack maps. It’s recommended to conservatively assume that any Wasmtime embedding that runs Wasm modules using reference types is vulnerable, regardless of the host’s native CPU architecture.

This bug was discovered when we discovered that Wasmtime’s fuzz target for exercising GC and stack maps, table_ops, was mistakenly not performing any actual work, and hadn’t been for some time now. This meant that while the fuzzer was reporting success it wasn’t actually doing anything substantive. After the fuzz target was fixed to exercise what it was meant to, it quickly found this issue. Further testing has been added to this fuzz target to ensure that in the future we’ll detect if it’s failing to exercise GC.

This bug was introduced in Cranelift’s migration to the regalloc2 register allocator in the Wasmtime 0.37.0 release on 2022-05-20. This migration introduced the concept of “aliased virtual registers” internally to avoid some inefficiencies related to the previous register allocator, but aliasing resolution was accidentally not applied to one of the inputs provided to the new register allocator, namely the list of virtual registers that hold reference values. This mistakenly tricked regalloc2 into thinking that registers with reference-typed values were not live when in fact they were live, and because it believed that the values were not live, it elided a stack map for them.

Patches

This bug has been patched and users should upgrade to Wasmtime version 0.38.2.

Workarounds

Mitigations for this issue can be achieved by doing one of:

• Disabling the reference types proposal by passing false to wasmtime::Config::wasm_reference_types.
• Downgrading to Wasmtime 0.36.0 or prior.

References

• The WebAssembly reference types proposal, which introduces externrefs

For more information

If you have any questions or comments about this advisory:

• Reach out to us on the Bytecode Alliance Zulip chat
• Open an issue in the bytecodealliance/wasmtime repository