This project contains known security vulnerabilities. Find detailed information at the bottom.

Crate pgn-reader

Dependencies

(4 total, 2 outdated, 1 insecure)

CrateRequiredLatestStatus
 btoi^0.40.4.3up to date
 memchr^2.12.7.2up to date
 shakmaty^0.140.26.0out of date
 slice-deque ⚠️^0.1.160.3.0insecure

Dev dependencies

(5 total, 2 outdated, 1 possibly insecure)

CrateRequiredLatestStatus
 bzip2 ⚠️^0.30.4.4out of date
 crossbeam^0.70.8.4out of date
 flate2^1.01.0.28up to date
 lz4^1.231.24.0up to date
 xz2^0.10.1.7up to date

Security Vulnerabilities

slice-deque: Bug in SliceDeque::move_head_unchecked corrupts its memory

RUSTSEC-2019-0002

Affected versions of this crate entered a corrupted state if mem::size_of::<T>() % allocation_granularity() != 0 and a specific allocation pattern was used: sufficiently shifting the deque elements over the mirrored page boundary.

This allows an attacker that controls controls both element insertion and removal to corrupt the deque, such that reading elements from it would read bytes corresponding to other elements in the deque. (e.g. a read of T could read some bytes from one value and some bytes from an adjacent one, resulting in a T whose value representation is not meaningful). This is undefined behavior.

The flaw was corrected by using a pair of pointers to track the head and tail of the deque instead of a pair of indices. This pair of pointers are represented using a Rust slice.

slice-deque: SliceDeque::drain_filter can double drop an element if the predicate panics

RUSTSEC-2021-0047

Affected versions of the crate incremented the current index of the drain filter iterator before calling the predicate function self.pred.

If the predicate function panics, it is possible for the last element in the iterator to be dropped twice.

bzip2: bzip2 Denial of Service (DoS)

RUSTSEC-2023-0004

Working with specific payloads can cause a Denial of Service (DoS) vector.

Both Decompress and Compress implementations can enter into infinite loops given specific payloads entered that trigger it.

The issue is described in great detail in the bzip2 repository issue.

Thanks to bjrjk for finding and providing the patch for the issue and the maintainer responsibly responding to release a fix quickly.

Users who use the crate with untrusted data should update the bzip2 to 0.4.4.