ghsa

On certain platforms, if a user has more than 16 groups, the `nix::unistd::getgrouplist` function will call the libc `getgrouplist` function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption. The libc `getgrouplist` function takes an in/out parameter `ngroups` specifying the size of the group buffer. When the buffer is too small to hold all of the reqested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify `ngroups` to indicate the actual number of groups for the user, in addition to returning an error. The version of `nix::unistd::getgrouplist` in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the `ngroups` variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to `getgrouplist` will then write past the end of the buffer. The issue would require editing /etc/gro...

Neon provides functionality for creating JavaScript `ArrayBuffer` (and the `Buffer` subtype) instances backed by bytes allocated outside of V8/Node. The [`JsArrayBuffer::external`](https://docs.rs/neon/0.10.0/neon/types/struct.JsArrayBuffer.html#method.external) and [`JsBuffer::external`](https://docs.rs/neon/0.10.0/neon/types/struct.JsBuffer.html#method.external) did not require `T: 'static` prior to Neon `0.10.1`. This allowed creating an externally backed buffer from types that may be freed while they are still referenced by a JavaScript `ArrayBuffer`. The following example demonstrates use after free. It compiles on versions `<0.10.1` and fails to compile afterward. ```rust pub fn soundness_hole(mut cx: FunctionContext) -> JsResult<JsArrayBuffer> { let mut data = vec![0u8, 1, 2, 3]; // Creating an external from `&mut [u8]` instead of `Vec<u8>` since there is a blanket impl // of `AsMut<T> for &mut T` let buf = JsArrayBuffer::external(&mut cx, data.as_mut_slic...

`TlsWyRand`'s implementation of `Deref` unconditionally dereferences a raw pointer, and returns multiple mutable references to the same object, which is undefined behavior.

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.