Vulnerability HighRUSTSEC-2020-0017 · internment
RUSTSEC-2020-0017: Use after free in ArcIntern::drop
Short answerA security vulnerability in the internment crate: Use after free in ArcIntern::drop. High severity (CVSS 8.1). Fixed in 0.4.0: update to a fixed version.
| Crate | internment |
|---|---|
| Type | Vulnerability (memory-corruption) |
| Affected versions | From 0.3.12 before 0.4.0. |
| Fixed in | 0.4.0 |
| Severity | High, CVSS 8.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Published | 2020-05-28 |
| Last changed | 2023-11-08 |
| Also known as | CVE-2020-35874, GHSA-96w3-p368-4h8c |
| Affected functions | internment::ArcIntern::drop |
What to do
- See which version you have:
cargo tree -i internment(it also shows which of your dependencies pulls it in). - Update within your version requirement:
cargo update -p internment. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for exampleinternment = "0.4.0") or update the dependency that pulls it in. - Check again with
cargo audit, or paste your Cargo.lock into our Cargo.toml checker.
Details from the advisory
ArcIntern::drop has a race condition where it can release memory which is about to get another user. The new user will get a reference to freed memory.
This was fixed by serializing access to an interned object while it is being deallocated.
Versions prior to 0.3.12 used stronger locking which avoided the problem.
References
- Package: crates.io/crates/internment
- Advisory: rustsec.org/advisories/RUSTSEC-2020-0017.html
- Report: github.com/droundy/internment/issues/11
From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.
Other advisories for internment
Up next
Same crateinternment: security historyEvery advisory for this crate, and whether it is safe to use today.Read it next →Did this answer your question?