CVE-2023-26489: Cranelift-codegen Buffer Overflow Bug

CVE-2023-26489 Overview

CVE-2023-26489 is a critical out-of-bounds memory access vulnerability in Wasmtime's code generator, Cranelift, affecting x86_64 targets. The bug causes address-mode computation to mistakenly calculate a 35-bit effective address instead of WebAssembly's defined 33-bit effective address. This allows a wasm-controlled load/store operation to read or write memory addresses up to approximately 34GB away from the base of linear memory, enabling malicious WebAssembly modules to access memory belonging to other instances or the host system without the embedder's knowledge.

Critical Impact

Malicious WebAssembly modules can read/write memory up to ~34GB away from linear memory base, potentially accessing memory of other WebAssembly instances when using the pooling allocator, leading to sandbox escape and cross-instance data compromise.

Affected Products

• bytecodealliance wasmtime versions prior to 4.0.1, 5.0.1, and 6.0.1
• bytecodealliance cranelift-codegen versions 0.92.0 and 0.93.0
• All Wasmtime deployments using default codegen settings on x86_64 architecture

Discovery Timeline

• 2023-03-08 - CVE CVE-2023-26489 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-26489

Vulnerability Analysis

The vulnerability resides in Cranelift's x86_64 backend lowering rules that handle zero-extended address computations. When a WebAssembly address is left-shifted by a constant amount from 1 to 3, Cranelift incorrectly folds this computation into x86_64's addressing modes that perform shifts. The core issue is that the address computation happens with 64-bit values when the intermediate $local0 << shift computation should have been truncated to a 32-bit value.

For example, the WebAssembly instruction (i32.load (i32.shl (local.get 0) (i32.const 3))) loads from address $local0 << 3. Cranelift generates an instruction like movl (%base, %local0, 8), %dst which calculates %base + %local0 << 3. However, because %local0 can use up to 32 bits and gets 3 extra bits from the shift operation, addresses up to 0xffffffff * 8 + 0x7ffffffc = 36507222004 bytes (~34GB) from linear memory base become accessible.

Root Cause

The root cause is erroneous lowering rules in Cranelift's x86_64 backend that handle uextend (zero-extension) of shifted values. The backend assumed it could fold the zero-extended shift directly into the x86_64 addressing mode, but this failed to account for the required 32-bit truncation of the intermediate computation. The uextend operation was being incorrectly looked through when optimizing address mode generation, allowing the full 64-bit computation to occur in the addressing mode rather than truncating to 32 bits first.

Attack Vector

An attacker can craft a malicious WebAssembly module that exploits this vulnerability through network-accessible Wasmtime instances. The attack requires the ability to load and execute WebAssembly code on an affected x86_64 system using default codegen settings. By carefully constructing memory access operations with left-shifted addresses, a malicious module can:

1. Read sensitive data from memory regions up to 34GB away from its allocated linear memory
2. Write arbitrary data to these memory regions, potentially corrupting other WebAssembly instance data
3. When using the pooling allocator, access memory belonging to other concurrently running WebAssembly instances

 (rule 2 (amode_add (Amode.ImmReg off (valid_reg base) flags) (ishl index (iconst (uimm8 shift))))
       (if (u32_lteq (u8_as_u32 shift) 3))
       (Amode.ImmRegRegShift off base index shift flags))
-(rule 2 (amode_add (Amode.ImmReg off (valid_reg base) flags) (uextend (ishl index (iconst (uimm8 shift)))))
-      (if (u32_lteq (u8_as_u32 shift) 3))
-      (Amode.ImmRegRegShift off base (extend_to_gpr index $I64 (ExtendKind.Zero)) shift flags))
-
-;; Same, but with a uextend of a shift of a 32-bit add. This is valid
-;; because we know our lowering of a narrower-than-64-bit `iadd` will
-;; always write the full register width, so we can effectively ignore
-;; the `uextend` and look through it to the `ishl`.
-;;
-;; Priority 3 to avoid conflict with the previous rule.
-(rule 3 (amode_add (Amode.ImmReg off (valid_reg base) flags)
-                   (uextend (ishl index @ (iadd _ _) (iconst (uimm8 shift)))))
-      (if (u32_lteq (u8_as_u32 shift) 3))
-      (Amode.ImmRegRegShift off base index shift flags))
 
 ;; -- Case 4 (absorbing constant offsets).
 ;;

Source: GitHub Commit 63fb30e4

Detection Methods for CVE-2023-26489

Indicators of Compromise

• Anomalous memory access patterns in WebAssembly instances accessing addresses significantly beyond allocated linear memory boundaries
• Unusual number of memory traps or segmentation faults during WebAssembly execution that may indicate probing attempts
• WebAssembly modules containing specific patterns of i32.shl combined with memory load/store operations using shift values 1-3

Detection Strategies

• Analyze preexisting WebAssembly modules for patterns matching the vulnerable codegen rules, specifically ishl operations with constants 1-3 followed by memory operations
• Correlate historical execution logs for anomalous trap counts that may indicate exploitation attempts
• Monitor for WebAssembly modules attempting to access memory regions outside expected boundaries using memory-safe instrumentation

Monitoring Recommendations

• Implement runtime monitoring for memory access patterns in Wasmtime deployments, particularly watching for accesses beyond the expected 33-bit address space
• Enable detailed logging of WebAssembly execution traps and correlate with specific module behavior
• Deploy canary values in memory regions between 6GB and 34GB from linear memory base to detect unauthorized access attempts

How to Mitigate CVE-2023-26489

Immediate Actions Required

• Update Wasmtime to patched versions 4.0.1, 5.0.1, or 6.0.1 immediately
• Audit existing WebAssembly modules for suspicious memory access patterns involving shifted addresses
• If immediate patching is not possible, apply one of the documented workarounds below
• Consider temporarily switching to non-x86_64 hosts (e.g., AArch64) as the vulnerability does not affect other architectures

Patch Information

Wasmtime versions 4.0.1, 5.0.1, and 6.0.1 have been released with the fix. The patch removes the erroneous lowering rules in Cranelift's x86_64 backend that allowed folding zero-extended shifted values directly into addressing modes. The fixed code now generates intermediate instructions that properly truncate the 32-bit computation before adding to the base address. For example, the vulnerable pattern is now translated to movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst which correctly truncates the intermediate computation. See the GitHub Security Advisory GHSA-ff4p-7xrq-q5r8 for complete details.

Workarounds

• Apply Config::static_memory_maximum_size(0) to force explicit bounds checking on all linear memory accesses, though this significantly impacts execution performance
• Configure Config::static_memory_guard_size(1 << 36) to reserve ~64GB of virtual memory as guard pages, ensuring accesses up to 34GB are semantically correct (note: this greatly reduces maximum concurrent instances)
• Deploy on non-x86_64 architectures such as AArch64 which are not affected by this vulnerability

# Wasmtime configuration workaround example (Rust)
# Option 1: Force explicit bounds checking (performance impact)
# config.static_memory_maximum_size(0);

# Option 2: Increase guard page size (memory overhead)
# config.static_memory_guard_size(1 << 36);

# Recommended: Update to patched version
cargo update -p wasmtime --precise 6.0.1