GHSA-wwq9-3cpr-mm53 json
Borsh serialization of HashMap is non-canonical
published 2y ago modified 2mo ago also RUSTSEC-2024-0402
- 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
The borsh serialization of the HashMap did not follow the borsh specification. It potentially produced non-canonical encodings dependent on insertion order. It also did not perform canonicty checks on decoding.
This can result in consensus splits and cause equivalent objects to be considered distinct.
This was patched in 0.15.1.
Patch / fix
- crates.io hashbrown 0.15.1
Is GHSA-wwq9-3cpr-mm53 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 | hashbrown | >=0.15.0, <0.15.1 |
0.15.1 |
Classification
- Weakness
-
- CWE-502 Deserialization of Untrusted Data
References
-
github.com
/rust-lang/hashbrown/issues/576
web, report
-
github.com
/kayabaNerve/hashbrown-borsh-poc
web
-
github.com
/rust-lang/hashbrown
package
-
rustsec.org
/advisories/RUSTSEC-2024-0402.html
web, advisory
-
crates.io
/crates/hashbrown
package
Sources
- GitHub Advisory GHSA-wwq9-3cpr-mm53
- OSV RUSTSEC-2024-0402
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.