RUSTSEC-2020-0072: GenericMutexGuard allows data races of non-Sync types across threads

What to do

1. See which version you have: cargo tree -i futures-intrusive (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p futures-intrusive. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example futures-intrusive = "0.4.0") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

GenericMutexGuard<T> was given the Sync auto trait as long as T is Send due to its contained members. However, since the guard is supposed to represent an **acquired lock** and allows concurrent access to the underlying data from different threads, it should only be Sync when the underlying data is.

This is a soundness issue and allows data races, potentially leading to crashes and segfaults from safe Rust code.

The flaw was corrected by adding a T: Send + Sync bound for GenericMutexGuard's Sync trait.

This bug is similar to one in std::sync::Mutex.

References

• Package: crates.io/crates/futures-intrusive
• Advisory: rustsec.org/advisories/RUSTSEC-2020-0072.html
• Report: github.com/Matthias247/futures-intrusive/issues/53

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.