Skip to content
Fencer Intel
medium —

GHSA-qvc4-78gw-pv8p json

Adverserial use of `make_bitflags!` macro can cause undefined behavior

published 3y ago modified 3y ago also RUSTSEC-2023-0035

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

The macro relied on an expression of the form `Enum::Variant` always being a variant of the enum. However, it may also be an associated integer constant, in which case there's no guarantee that the value of said constant consists only of bits valid for this bitflag type.

Thus, code like this could create an invalid `BitFlags<Test>`, which would cause iterating over it to trigger undefined behavior. As the debug formatter internally iterates over the value, it is also affected.

```rust use enumflags2::{bitflags, make_bitflags};

#[bitflags] #[repr(u8)] #[derive(Copy, Clone, Debug)] enum Test { A = 1, B = 2, }

impl Test { const C: u8 = 69; }

fn main() { let x = make_bitflags!(Test::{C}); // printing or iterating over x is UB } ```

Patch / fix

  • crates.io enumflags2 0.7.7

Is GHSA-qvc4-78gw-pv8p 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 enumflags2
>=0.7.0, <0.7.7
0.7.7

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.