WebAssembly allocator shim corrupts memory on allocation failure
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 2.1.2
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The zstd-sys Rust crate, when compiled for WebAssembly (wasm32), has a memory allocator shim used by its bundled C zstd library that failed to handle allocation failures. Decompressing a small crafted zstd frame in a memory-constrained WebAssembly instance could corrupt the module's linear memory instead of returning an error, with the corruption contained within the wasm sandbox.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
On wasm32, zstd-sys provides `malloc` and `free` to the C library through a shim over Rust's allocator. The shim did not check for allocation failure: it wrote its size header to address 0 and returned address 4, which the C library used as a valid buffer. `free(NULL)` also read below address 0. Whenever the instance cannot grow its memory by what a frame asks for, a small crafted frame (a 9-byte header declaring a 128 MiB window is enough) made decompression write decoded data over the bottom of the module's linear memory, instead of failing. The corruption stays within the wasm sandbox. The flaw was corrected by returning NULL on allocation failure or size overflow, and by making `free(NULL)` a no-op.
Timeline
- Advisory published
- Record last updated
Affected versions
- zstd-syscrates.io
From 2.0.9 · fixed in 2.1.2