ghsa

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>...

Affected version of this crate, which is a required dependency in com-impl, provides a faulty implementation of the `IUnknown::QueryInterface` method. `QueryInterface` implementation must call `IUnknown::AddRef` before returning the pointer, as describe in this documentation: <https://docs.microsoft.com/en-us/windows/win32/api/unknwn/nf-unknwn-iunknown-queryinterface(refiid_void)> As it is not incrementing the refcount as expected, the following calls to `IUnknown::Release` method will cause WMI to drop reference to the interface, and can lead to invalid reference. This is documented in <https://docs.microsoft.com/en-us/windows/win32/learnwin32/managing-the-lifetime-of-an-object#reference-counting> There is no simple workaround, as you can't know how many time QueryInterface will be called. The only way to quick fix this is to use the macro expanded version of the code and modify the QueryInterface method to add the AddRef call yourself. The issue was corrected in commit `9803f...

Reference returned by some methods of `Ref` (and similar types) may outlive the `Ref` and escape the lock. This causes undefined behavior and may result in a segfault. More information in [`dashmap#167`](https://github.com/xacrimon/dashmap/issues/167) issue.

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation (within `fn preamble_skipcount()`). 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.

The implementation does not enforce alignment requirements on input slices while incorrectly assuming 4-byte alignment through an unsafe call to `std::slice::from_raw_parts_mut`, which breaks the contract and introduces undefined behavior. This affects Chacha20 encryption and decryption in crypto2.

Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null). The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.

Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null). The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.

Affected versions of this crate called `mem::zeroed()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null). The flaw was corrected by avoiding the use of `mem::zeroed()`, using `MaybeUninit` instead.