Skip to content
Fencer Intel
medium —

GHSA-83gg-pwxf-jr89 json

`array!` macro is unsound in presence of traits that implement methods it calls internally

published 6y ago modified 3y ago also RUSTSEC-2020-0161

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

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.

Patch / fix

  • crates.io array-macro 1.0.5

Is GHSA-83gg-pwxf-jr89 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
crates.io array-macro
>=0.1.2, <1.0.5
1.0.5

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.