ghsa

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

An incorrect mapping from HTML specification to ASCII codes was used. Because HTML treats the Form Feed as whitespace, code like this has an injection bug: let html = format!("<div title={}>", clean_text(user_supplied_string)); Applications are not affected if they quote their attributes, or if they don't use `clean_text` at all.

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.

This transmute is at the core of the abomonation crates. It's so easy to use it to violate alignment requirements that no test in the crate's test suite passes under miri. The use of this transmute in serialization/deserialization also incorrectly assumes that the layout of a repr(Rust) type is stable. This transmute can also disclose both the contents of padding bytes which may be an information leak and the contents of pointers, which may be used to defeat ASLR.

### Impact This vulnerability allows attackers who have control over a given apps update server / update storage to serve maliciously crafted update packages that pass the code signing validation check but contain malicious code in some components. Please note that this kind of attack would require **significant** privileges in your own auto updating infrastructure and the ease of that attack entirely depends on your infrastructure security. ### Patches This has been patched and the following Electron versions contain the fix: * `18.0.0-beta.6` * `17.2.0` * `16.2.0` * `15.5.0` ### Workarounds There are no workarounds for this issue, please update to a patched version of Electron. ### For more information If you have any questions or comments about this advisory, email us at [[email protected]](mailto:[email protected]).