Skip to content
Fencer Intel
medium —

GHSA-7v4j-8wvr-v55r json

`array!` macro is unsound when its length is impure constant

published 4y ago modified 3y ago also RUSTSEC-2022-0017

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 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://github.com/xfix/array-macro/commit/d5b63f72090f3809c21ac28f9cfd84f12559bf7d) by making sure that array length is substituted just once.

Patch / fix

  • crates.io array-macro 2.1.2

Is GHSA-7v4j-8wvr-v55r 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
>=2.1.0, <2.1.2
2.1.2

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.