Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
`ZDICT_trainFromBuffer` is never told the length of the samples buffer. Before 0.4.10, `zstd::dict::from_continuous` (initially `train_dict`) called it directly: up to 0.2.1 without checking the sample sizes against the buffer at all, and from 0.3.0 with a sum that wraps around when overflow checks are off, as in release builds. Sizes that do not describe the buffer made the trainer read past its end. This requires the sample sizes to come from an untrusted source. From 0.4.10, training goes through zstd-safe, where the same flaw is covered by the zstd-safe advisory for it, fixed in zstd-safe 8.2.0.
Recommended action: Upgrade to 0.4.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `with_context` constructors of the stream encoders and decoders used the borrowed context as it was. When a stream was abandoned on a context, for example an encoder dropped before `finish()` after an error, whatever it left there was carried into the next stream: the input buffered by the previous encoder (up to 128 KiB, or all of it with `zstdmt`) became the start of the next frame, and a decoder returned undelivered output of the previous stream. An application reusing one context for data that must stay separate, such as different users' requests, could disclose one user's plaintext to another. Whoever supplies the data can cause the abandonment with invalid input. The flaw was corrected by resetting the context's session in `with_context`.
Recommended action: Upgrade to 0.14.3 or 0.13.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.