CVE-2020-36220
Description
A missing Send bound on Demuxer in the va-ts crate (before 0.0.4) can cause data races and memory corruption when non-Send types are moved across threads.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A missing `Send` bound on `Demuxer` in the va-ts crate (before 0.0.4) can cause data races and memory corruption when non-Send types are moved across threads.
Root
Cause
The va-ts crate provides an MPEG-TS demuxer structure Demuxer that unconditionally implements Send via: unsafe impl Send for Demuxer where T: DemuxerEvents {}. This implementation omits the required T: Send bound, meaning that even if type T contains non-Send types (e.g., MutexGuard, Rc, or Cell), the Demuxer can be sent across thread boundaries. The Rust advisory RUSTSEC-2020-0114 and the GitHub issue filed by researchers at Georgia Tech explicitly identify this as the flaw [2][3].
Exploitation
An attacker or untrusted code can exploit this by providing a Demuxer where T is a type that holds a non-Send object, such as a MutexGuard that is tied to a specific thread. The proof-of-concept in the GitHub issue demonstrates moving a MutexGuard into a Demuxer and then spawning a new thread that takes ownership of the demuxer. Dropping the MutexGuard on the wrong thread results in undefined behavior (including mutex corruption) [3]. Because the exploit requires crafting the generic type T and controlling the data moved into the demuxer, the attack complexity is considered high, and no authentication is needed if the vulnerable code path is exposed over a network [2].
Impact
A successful exploitation leads to a data race (e.g., concurrent unsynchronized access via Rc/Cell) or memory corruption. The RustSec advisory classifies the severity as Medium (CVSS 5.9) with a high impact on availability, while confidentiality and integrity are marked as none [2]. The core risk is thread-safety violation that can cause crashes or undefined program behavior.
Mitigation
Users are advised to update the va-ts crate to version 0.0.4 or later, where the Send impl was corrected to include the T: Send bound (where T: DemuxerEvents + Send). No public workarounds other than upgrading have been documented. The issue was reported on December 22, 2020, and patched in the January 2021 release [2][3][4].
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
va-tscrates.io | < 0.0.4 | 0.0.4 |
Affected products
2- Rust/va-tsdescription
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing `T: Send` bound on the `unsafe impl Send for Demuxer<T>` allows non-Send types (e.g., `MutexGuard`, `Rc`, `Cell`) to be moved across thread boundaries, causing data races and memory corruption."
Attack vector
An attacker who can control or influence the type parameter `T` of `Demuxer<T>` can instantiate it with a non-Send type such as `MutexGuard` or `Rc`. Because the crate unconditionally implements `Send` for `Demuxer<T>` without requiring `T: Send` [ref_id=1], the compiler does not prevent the `Demuxer` from being sent to another thread via `std::thread::spawn`. Once on a different thread, dropping the `Demuxer` drops the inner non-Send value, which can unlock a mutex from the wrong thread or cause concurrent unsynchronized access to shared state — both are undefined behavior [CWE-662] [CWE-667].
Affected code
The vulnerable code is the `unsafe impl<T> Send for Demuxer<T> where T: DemuxerEvents {}` line in the va-ts crate [ref_id=1]. This unconditional `Send` implementation on `Demuxer<T>` omits the required `T: Send` bound, allowing any `T` (including non-Send types) to be transferred across threads.
What the fix does
The fix adds `+ Send` to the trait bound on the `unsafe impl Send for Demuxer<T>` declaration, changing it from `where T: DemuxerEvents` to `where T: DemuxerEvents + Send` [ref_id=1]. This allows the compiler to statically reject any `Demuxer<T>` where `T` does not implement `Send`, preventing non-Send types like `MutexGuard` or `Rc` from being moved across threads. No patch file is included in the bundle; the advisory from the crate's issue tracker provides the remediation guidance [ref_id=1].
Preconditions
- inputThe attacker must be able to supply or influence the type parameter T of Demuxer to be a non-Send type (e.g., MutexGuard, Rc, Cell).
- networkThe Demuxer instance must be moved to another thread (e.g., via thread::spawn).
Reproduction
The following PoC from [ref_id=1] reproduces the issue:
```rust use va_ts::{Demuxer, DemuxerEvents, SubtableID, DemuxedPacket, DemuxedTable}; use std::sync::{Mutex, MutexGuard}; use std::thread::{self, ThreadId}; use std::ops::Drop;
struct X(MutexGuard<'static, u64>, ThreadId); impl DemuxerEvents for X { fn on_table(&mut self, _: SubtableID, _: &DemuxedTable) { } fn on_packet(&mut self, _: &DemuxedPacket) { } } impl Drop for X { fn drop(&mut self) { assert_eq!(self.1, thread::current().id()); } }
fn main() { let static_mutex = Box::leak(Box::new(Mutex::new(0xbeefbeef_u64))); let mutex_guard = static_mutex.lock().unwrap(); let tid = thread::current().id(); let demuxer = Demuxer::new(X(mutex_guard, tid)); std::thread::spawn(move || { let demuxer = demuxer; }).join().unwrap(); } ```
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4- github.com/advisories/GHSA-3hj2-hh36-hv9vghsaADVISORY
- nvd.nist.gov/vuln/detail/CVE-2020-36220ghsaADVISORY
- github.com/video-audio/va-ts/issues/4ghsaWEB
- rustsec.org/advisories/RUSTSEC-2020-0114.htmlghsax_refsource_MISCWEB
News mentions
0No linked articles in our index yet.