Uninitialized memory exposed by `write::Decoder` on a corrupt legacy frame
- 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 0.8.0
- 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 Rust `zstd` crate, specifically its `zstd::stream::write::Decoder` component, is affected in versions from 0.4.22 through 0.7.x. When a corrupt legacy-format frame fails to decompress, the decoder can pass stale uninitialized heap memory, up to 32 KiB by default, to the wrapped writer, potentially exposing sensitive data depending on where the output is sent.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
From 0.4.22 to 0.7.x, the writer behind `zstd::stream::write::Decoder` set its output buffer's length to its full capacity before each decompression call, then to the position the call reported, and only checked for an error afterwards. When decompression fails inside a legacy (zstd v0.4 to v0.7) frame, the bundled zstd library reports the output as fully written although nothing was written, so stale heap memory, up to the buffer size (32 KiB by default), was passed to the wrapped writer. Legacy support is enabled by default, and a few bytes of corrupt legacy frame are enough. Whether this reaches an attacker depends on where the application sends the decompressed output. From 0.8.0, the writer uses zstd-safe's buffers, and the same flaw there is covered by the zstd-safe advisory for it, fixed in zstd-safe 8.2.0.
Timeline
- Advisory published
- Record last updated
Affected versions
- zstdcrates.io
From 0.4.22 · fixed in 0.8.0