GHSA-rxhx-9fj6-6h2m

Source

https://github.com/advisories/GHSA-rxhx-9fj6-6h2m

Import Source

https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2022/06/GHSA-rxhx-9fj6-6h2m/GHSA-rxhx-9fj6-6h2m.json

Aliases

• RUSTSEC-2022-0010

Published

2022-06-16T23:53:32Z

Modified

2023-11-08T04:22:58.719670Z

Details

Affected versions of this crate did not properly check the length of an enum when using enum_map! macro, trusting user-provided length.

When the LENGTH in the Enum trait does not match the array length in the EnumArray trait, this can result in the initialization of the enum map with uninitialized types, which in turn can allow an attacker to execute arbitrary code.

This problem can only occur with a manual implementation of the Enum trait, it will never occur for enums that use #[derive(Enum)].

Example code that triggers this vulnerability looks like this:

enum E {
    A,
    B,
    C,
}

impl Enum for E {
    const LENGTH: usize = 2;

    fn from_usize(value: usize) -> E {
        match value {
            0 => E::A,
            1 => E::B,
            2 => E::C,
            _ => unimplemented!(),
        }
    }

    fn into_usize(self) -> usize {
        self as usize
    }
}

impl<V> EnumArray<V> for E {
    type Array = [V; 3];
}

let _map: EnumMap&lt;E, String> = enum_map! { _ => "Hello, world!".into() };

The flaw was corrected in commit b824e23 by putting LENGTH property on sealed trait for macro to read.

References

• https://github.com/xfix/enum-map/commit/b824e232f2fb47837740070096ac253df8e80dfc
• https://github.com/rustsec/advisory-db/blob/main/crates/enum-map/RUSTSEC-2022-0010.md
• https://github.com/xfix/enum-map
• https://github.com/xfix/enum-map/blob/master/CHANGELOG.md#version-202
• https://gitlab.com/KonradBorowski/enum-map/-/blob/master/CHANGELOG.md#version-202
• https://rustsec.org/advisories/RUSTSEC-2022-0010.html