`Seekable::decompress` sets a `Vec` length beyond its capacity for offsets past the end
- 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 8.2.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 seekable-archive decompression feature (`Seekable::decompress`), is affected. An attacker who supplies a crafted archive or chooses the read offset can make the caller's buffer report a length larger than its allocated memory, which can leak nearby heap contents or corrupt memory when the buffer is written to, and can also hang the call.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
`ZSTD_seekable_decompress` shortens the requested length to the end of the data without checking that the offset is before it. For an offset past the end, it returns a wrapped-around length without writing anything, and `Seekable::decompress` passed that length to `Vec::set_len`. With the `seekable` feature, whoever supplies the archive, or chooses the offset, can leave the caller's `Vec<u8>` with a length far beyond its capacity. Reading it then discloses neighbouring heap memory, and appending to it corrupts memory. Offsets near `u64::MAX` can also hang the call. The flaw was corrected by clamping requests to the end of the data, and by checking every count reported by the C library against the buffer capacity.
Timeline
- Advisory published
- Record last updated
Affected versions
- zstd-safecrates.io
From 7.2.2 · fixed in 8.2.0