ghsa

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.

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

### Impact Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. ### Workarounds No workarounds are known. ### References - [time-rs/time#293](https://github.com/time-rs/time/issues/293)

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.