CVE-2021-32629

7.2 HIGH

📋 TL;DR

A code generation bug in Cranelift 0.73's x64 backend incorrectly sign-extends instead of zero-extends certain i32 values, potentially allowing WebAssembly programs to access memory up to 2GiB before their heap start. This could lead to sandbox escape in affected WebAssembly runtimes. Systems using Cranelift-based WebAssembly runtimes like Wasmtime or Lucet with vulnerable configurations are affected.

💻 Affected Systems

Products:
  • Cranelift
  • Wasmtime
  • Lucet
Versions: Cranelift 0.73 (default vulnerable), prior versions with explicit new backend flag
Operating Systems: All platforms using affected Cranelift versions
Default Config Vulnerable: ⚠️ Yes
Notes: Vulnerability requires specific conditions: i32 value ≥ 0x80000000, register spilling/reloading, and certain arithmetic operations.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Full sandbox escape allowing WebAssembly programs to read sensitive memory from the host process, potentially leading to information disclosure or further exploitation.

🟠

Likely Case

Limited memory disclosure depending on heap implementation and guard page configuration, potentially exposing adjacent memory regions.

🟢

If Mitigated

No impact if heap has proper bounds checks, guard pages, or no memory is mapped in the accessible range before the heap.

🌐 Internet-Facing: MEDIUM - WebAssembly runtimes processing untrusted Wasm code from external sources could be exploited.
🏢 Internal Only: LOW - Internal-only Wasm processing with trusted code sources reduces exposure.

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: UNKNOWN
Unauthenticated Exploit: ⚠️ Yes
Complexity: HIGH

Exploitation requires crafting specific WebAssembly code that triggers the register allocation bug under precise conditions.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Cranelift 0.74 or later

Vendor Advisory: https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5

Restart Required: Yes

Instructions:

1. Update Cranelift to version 0.74 or later. 2. Update dependent projects like Wasmtime to versions with the fix. 3. Recompile affected WebAssembly applications. 4. Restart services using the updated runtime.

🔧 Temporary Workarounds

Disable new x64 backend

all

Revert to using the old backend in versions before 0.73 where it was not default

Set build configuration to use old backend instead of new x64 backend

Implement heap guard regions

all

Ensure 2GiB unmapped memory region before WebAssembly heap to prevent memory access

🧯 If You Can't Patch

  • Isolate WebAssembly runtime execution in containers or VMs with minimal host access
  • Implement strict Wasm code validation and only allow trusted, verified WebAssembly modules

🔍 How to Verify

Check if Vulnerable:

Check Cranelift version in dependencies: cranelift-codegen = 0.73, or check Wasmtime/Lucet versions using vulnerable Cranelift.

Check Version:

cargo tree | grep cranelift-codegen or check package manifest for version

Verify Fix Applied:

Verify cranelift-codegen version is 0.74 or higher, or dependent runtime versions include the fix commit.

📡 Detection & Monitoring

Log Indicators:

  • Unexpected memory access errors in WebAssembly runtime logs
  • Sandbox violation alerts

Network Indicators:

  • Unusual outbound data from WebAssembly processing services

SIEM Query:

Search for process crashes or memory access violations in WebAssembly runtime processes

🔗 References

📤 Share & Export