Heap buffer overflow in `CCtx::try_clone` on a multithreaded context
- 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
This vulnerability affects the zstd compression library's experimental context-cloning function (`CCtx::try_clone`) when a multithreaded compression frame has been started on the context after an earlier single-threaded frame was abandoned. Exploiting it could corrupt the heap by writing up to 512 KiB past an allocated buffer or cause reads beyond one, potentially leading to crashes or memory disclosure.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
`CCtx::try_clone` (`experimental` feature, deprecated) copies tables sized from the context's applied parameters. Starting a multithreaded frame (`zstdmt` feature) replaces those parameters with the workers' without resizing the context's own tables, so after an abandoned single-threaded frame, the copy wrote up to 512 KiB past a heap allocation, or read past one. This became reachable with the bundled zstd 1.5.6. The flaw was corrected by refusing `try_clone` (and the unsafe `compress_block`) once `NbWorkers` was set on the context.
Timeline
- Advisory published
- Record last updated
Affected versions
- zstd-safecrates.io
From 4.1.4 · fixed in 8.2.0