This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.

Crate parry3d

Dependencies

(26 total, 1 outdated, 2 possibly insecure)

CrateRequiredLatestStatus
 approx^0.50.5.1up to date
 arrayvec^0.70.7.6up to date
 bitflags^2.32.9.2up to date
 bytemuck^11.23.2up to date
 downcast-rs^22.0.1up to date
 either^11.15.0up to date
 ena^0.14.30.14.3up to date
 glam^0.30.40.30.5up to date
 hashbrown ⚠️^0.150.15.5maybe insecure
 indexmap^22.10.0up to date
 log^0.40.4.27up to date
 nalgebra^0.340.34.0up to date
 num-derive^0.40.4.2up to date
 num-traits^0.20.2.19up to date
 obj^0.10.20.10.2up to date
 ordered-float^55.0.0up to date
 rayon^11.11.0up to date
 rkyv^0.7.410.8.11out of date
 rstar^0.12.00.12.2up to date
 serde^1.01.0.219up to date
 simba^0.90.9.0up to date
 slab^0.40.4.11up to date
 smallvec ⚠️^11.15.1maybe insecure
 spade^2.92.15.0up to date
 static_assertions^11.1.0up to date
 thiserror^22.0.15up to date

Dev dependencies

(6 total, 1 outdated)

CrateRequiredLatestStatus
 macroquad^0.4.120.4.14up to date
 nalgebra^0.340.34.0up to date
 oorandom^1111.1.5up to date
 ptree^0.4.00.5.2out of date
 rand^0.90.9.2up to date
 rand_isaac^0.40.4.0up to date

Security Vulnerabilities

smallvec: Buffer overflow in SmallVec::insert_many

RUSTSEC-2021-0003

A bug in the SmallVec::insert_many method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap.

This bug was only triggered if the iterator passed to insert_many yielded more items than the lower bound returned from its size_hint method.

The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of insert_many to use less unsafe code, so it is easier to verify its correctness.

Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.

hashbrown: Borsh serialization of HashMap is non-canonical

RUSTSEC-2024-0402

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.