GHSA-7hc7-h3f2-r4j6 json
Safe ErrorRegistry APIs can cause undefined behavior
published 3mo ago modified last mo. also RUSTSEC-2026-0242
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
All published versions of `dcrypt-api` before 2.0.0 exposed safe `ErrorRegistry` operations that could trigger undefined behavior when the default `std` feature was enabled.
Stored `Box<E>` values were erased to raw pointers and later deallocated as `Box<()>`. The `get_error<E>` operation also performed an unchecked cast to a caller-selected type. Finally, concurrent replacement or clearing could free a value while another thread cloned it. Ordinary safe Rust could therefore cause mismatched deallocation, type confusion, and use-after-free. Crates that re-exported this API are affected transitively.
Version 2.0.0 replaces the raw pointers with owned `Box<dyn Any + Send>` values behind a mutex, performs checked downcasts, and uses a mutation generation so concurrent stores and clears win safely. There is no reliable workaround while calling the affected registry API. Upgrade to 2.0.0 or later and avoid process-global error state where possible.
Patch / fix
- crates.io dcrypt-api 2.0.0
Is GHSA-7hc7-h3f2-r4j6 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | dcrypt-api | >=0.0.0-0, <2.0.0 |
2.0.0 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.