github-actions[bot] opened issue #15004:
Uninitialized memory exposed when streaming decompression of a legacy frame fails
Details Package zstd-safeVersion 5.0.2+zstd.1.5.2URL https://github.com/gyscos/zstd-rs/commit/006e1d1ad1eeaf6b5d4c28329e70217adabcec43 Date 2026-10-16 Patched versions >=8.2.0Unaffected versions <4.0.0When decompression fails inside a legacy (zstd v0.4 to v0.7) frame, the
bundled zstd library reports the output buffer as fully written although
nothing was written.DCtx::decompress_streamcommitted that position even
on error, and for aVec<u8>destination this extended the vector's length
over uninitialized memory.Legacy support is enabled by default. A 5- or 6-byte corrupt legacy frame is
enough: throughzstd::stream::write::Decoder, up to 32 KiB of stale heap
memory is then passed to the wrapped writer on the nextwrite()or
flush(), or when anauto_flush()/on_flush()decoder is dropped. Whether
this reaches an attacker depends on where the application sends the
decompressed output.zstd::stream::read::Decoder,zstd::decode_alland
the bulk API are not affected.Before zstd-safe 4.0.0, output buffers could only be initialized slices.
The zstd crate's own writer had the same flaw from 0.4.22 to 0.7.x, which is
covered by a separate advisory.The flaw was corrected by only committing the buffer positions of a
successful call.See advisory page for additional details.
pchickey closed issue #15004:
Uninitialized memory exposed when streaming decompression of a legacy frame fails
Details Package zstd-safeVersion 5.0.2+zstd.1.5.2URL https://github.com/gyscos/zstd-rs/commit/006e1d1ad1eeaf6b5d4c28329e70217adabcec43 Date 2026-10-16 Patched versions >=8.2.0Unaffected versions <4.0.0When decompression fails inside a legacy (zstd v0.4 to v0.7) frame, the
bundled zstd library reports the output buffer as fully written although
nothing was written.DCtx::decompress_streamcommitted that position even
on error, and for aVec<u8>destination this extended the vector's length
over uninitialized memory.Legacy support is enabled by default. A 5- or 6-byte corrupt legacy frame is
enough: throughzstd::stream::write::Decoder, up to 32 KiB of stale heap
memory is then passed to the wrapped writer on the nextwrite()or
flush(), or when anauto_flush()/on_flush()decoder is dropped. Whether
this reaches an attacker depends on where the application sends the
decompressed output.zstd::stream::read::Decoder,zstd::decode_alland
the bulk API are not affected.Before zstd-safe 4.0.0, output buffers could only be initialized slices.
The zstd crate's own writer had the same flaw from 0.4.22 to 0.7.x, which is
covered by a separate advisory.The flaw was corrected by only committing the buffer positions of a
successful call.See advisory page for additional details.
Last updated: Oct 31 2026 at 23:03 UTC