ghsa

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 calls a user provided `Read` implementation on an uninitialized buffer. `Read` on uninitialized buffer is defined as undefined behavior in Rust.

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation. The crate currently contains 4 occurrences of such cases. 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 struct `Ffi_ArrowArray` implements `#derive(Clone)` that is inconsistent with its custom implementation of `Drop`, resulting in a double free when cloned. Cloning this struct in `safe` results in a segmentation fault, which is unsound. This derive was removed from this struct. All users are advised to either: * bump the patch version of this crate (for versions `v0.7,v0.8,v0.9`), or * migrate to a more recent version of the crate (when using `<0.7`). Doing so elimitates this vulnerability (code no longer compiles).

`FixedSizeBinaryArray` performs insufficient bounds checks, which allows out-of-bounds reads in safe code.

`DecimalArray` performs insufficient bounds checks, which allows out-of-bounds reads in safe code if the lenght of the backing buffer is not a multiple of 16.

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.

`BinaryArray` performs insufficient validation on creation, which allows out-of-bounds reads in safe code.

Affected versions of this crate did substitute the array length provided by an user at compile-time multiple times. When an impure constant expression is passed as an array length (such as a result of an impure procedural macro), this can result in the initialization of an array with uninitialized types, which in turn can allow an attacker to execute arbitrary code. The flaw was corrected in commit [d5b63f72](https://gitlab.com/KonradBorowski/array-macro/-/commit/d5b63f72090f3809c21ac28f9cfd84f12559bf7d) by making sure that array length is substituted just once.

Affected versions of this crate called some methods using auto-ref. The affected code looked like this. ```rust let mut arr = $crate::__core::mem::MaybeUninit::uninit(); let mut vec = $crate::__ArrayVec::<T>::new(arr.as_mut_ptr() as *mut T); ``` In this case, the problem is that `as_mut_ptr` is a method of `&mut MaybeUninit`, not `MaybeUninit`. This made it possible for traits to hijack the method calls in order to cause unsoundness. ```rust trait AsMutPtr<T> { fn as_mut_ptr(&self) -> *mut T; } impl<T> AsMutPtr<T> for std::mem::MaybeUninit<T> { fn as_mut_ptr(&self) -> *mut T { std::ptr::null_mut() } } array![0; 1]; ``` The flaw was corrected by explicitly referencing variables in macro body in order to avoid auto-ref.