RUSTSEC-2026-0410 json
WebAssembly allocator shim corrupts memory on allocation failure
published 26d ago modified 16d ago
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
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.
Patch / fix
- crates.io zstd-sys 2.1.2
- github.com/gyscos/zstd-rs@165d162 commit
- github.com/gyscos/zstd-rs#384 pull request
Is RUSTSEC-2026-0410 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | zstd-sys | >=2.0.9, <2.1.2 |
2.1.2 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.