ghsa

In the affected versions of the crate, `AtomicBucket<T>` unconditionally implements `Send`/`Sync` traits. Therefore, users can create a data race to the inner `T: !Sync` by using the `AtomicBucket::data_with()` API. Such data races can potentially cause memory corruption or other undefined behavior. The flaw was fixed in commit 8e6daab by adding appropriate Send/Sync bounds to the Send/Sync impl of struct `Block<T>` (which is a data type contained inside `AtomicBucket<T>`).

The `mopa` crate redefines the deprecated `TraitObject` struct from `core::raw` like so: ```rust #[repr(C)] #[derive(Copy, Clone)] #[doc(hidden)] pub struct TraitObject { pub data: *mut (), pub vtable: *mut (), } ``` This is done to then transmute a reference to a trait object (`&dyn Trait` for any trait `Trait`) into this struct and retrieve the `data` field for the purpose of downcasting. This is used to implement `downcast_ref_unchecked()`, in terms of which `downcast_ref()` is also implemented. Same goes for mutable reference downcasting and `Box` downcasting. The Rust compiler explicitly reserves the right to change the memory layout of `&dyn Trait` for any trait `Trait`. The worst case scenario is that it swaps `data` and `vtable`, making an executable location breach and compromisation of ASLR possible, since reads from `data` would read `vtable` instead. Likewise, arbitrary code execution is also theoretically possible if reads of `vtable` generated by the compiler rea...

Affected versions of this crate passed an uninitialized buffer to a user-provided `Read` instance in: * `deserialize_binary` * `deserialize_string` * `deserialize_extension_others` * `deserialize_string_primitive` This can result in safe `Read` implementations reading from the uninitialized buffer leading to undefined behavior.

Lru crate has use after free vulnerability. Lru crate has two functions for getting an iterator. Both iterators give references to key and value. Calling specific functions, like pop(), will remove and free the value, and but it's still possible to access the reference of value which is already dropped causing use after free.

Affected versions of this crate did not check that the public key the signature was created with matches the peer ID of the peer record. Any combination was considered valid. This allows an attacker to republish an existing `PeerRecord` with a different `PeerId`.

Affected versions of this crate called `mem::uninitialized()` in the HTTP1 parser to create values of type `httparse::Header` (from the `httparse` crate). This is unsound, since `Header` contains references and thus must be non-null. The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation. Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation. There are two of such cases (`go_offset_log::read_entry()` & `offset_log::read_entry()`). Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior.

Code generated by flatbuffers' compiler is `unsafe` but not marked as such. See https://github.com/google/flatbuffers/issues/6627 for details. All users that use generated code by `flatbuffers` compiler are recommended to: 1. not expose flatbuffer generated code as part of their public APIs 2. audit their code and look for any usage of `follow`, `push`, or any method that uses them (e.g. `self_follow`). 3. Carefuly go through the crates' documentation to understand which "safe" APIs are not intended to be used.

Affected versions of this crate did not properly check the length of an enum when using `enum_map!` macro, trusting user-provided length. When the `LENGTH` in the `Enum` trait does not match the array length in the `EnumArray` trait, this can result in the initialization of the enum map with uninitialized types, which in turn can allow an attacker to execute arbitrary code. This problem can only occur with a manual implementation of the Enum trait, it will never occur for enums that use `#[derive(Enum)]`. Example code that triggers this vulnerability looks like this: ```rust enum E { A, B, C, } impl Enum for E { const LENGTH: usize = 2; fn from_usize(value: usize) -> E { match value { 0 => E::A, 1 => E::B, 2 => E::C, _ => unimplemented!(), } } fn into_usize(self) -> usize { self as usize } } impl<V> EnumArray<V> for E { type Array = [V; 3]; } let _map: EnumMap<E, String>...