---
id: RUSTSEC-2026-0406
title: Use-after-free when changing a multithreaded context with an unfinished frame
summary: Use-after-free when changing a multithreaded context with an unfinished frame
severity: none
vendor: zstd-safe
product: zstd-safe
ecosystem: rust
affected:
  - 'zstd-safe >= 0.0.0-0, < 8.2.0'
patched:
  - zstd-safe 8.2.0
published: '2026-10-16'
updated: '2026-10-26'
sourceUpdated: '2026-10-26T14:00:05.095427051Z'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/RUSTSEC-2026-0406'
references:
  - url: 'https://crates.io/crates/zstd-safe'
  - url: 'https://rustsec.org/advisories/RUSTSEC-2026-0406.html'
  - url: >-
      https://github.com/gyscos/zstd-rs/commit/e224018a2389915d68ed17f30109bebad36e9734
  - url: 'https://github.com/gyscos/zstd-rs/pull/384'
tags:
  - osv
  - rust
ingestedAt: '2026-10-27T16:20:12.118Z'
---

## Overview

When a multithreaded frame (`zstdmt` feature, `CParameter::NbWorkers`) is
left unfinished, its jobs may still be running on the worker threads: the C
library only waits for them when the next frame starts, or when the context
is freed. A session reset makes the context accept changes again in the
meantime, so:

- unloading the dictionary (`load_dictionary`, `ref_cdict`, `ref_prefix`,
  `disable_dictionary`, `init*`, or `reset` with parameters) freed the
  dictionary a worker was still compressing against;
- changing `NbWorkers` made the next frame resize the job table before
  waiting for the old jobs.

The flaw was corrected by refusing these calls while a multithreaded frame
is unfinished. The new `CCtx::wait_for_workers()` waits for the workers
first.

## Affected packages

- `zstd-safe >= 0.0.0-0, < 8.2.0`

## Remediation

Upgrade to a patched release:

- `zstd-safe 8.2.0`