Skip to content
Fencer Intel
low —

GHSA-h7h7-6mx3-r89v json

Fyrox has unsound usages of `Vec::from_raw_parts`

published last yr. modified 2mo ago also RUSTSEC-2024-0435

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 library provides a public safe API `transmute_vec_as_bytes`, which incorrectly assumes that any generic type `T` could have stable layout, causing to uninitialized memory exposure if the users pass any types with padding bytes as `T` and cast it to `u8` pointer.

In the [issue](https://github.com/FyroxEngine/Fyrox/issues/630), we develop a PoC to show passing struct type to `transmute_vec_as_bytes` could lead to undefined behavior with `Vec::from_raw_parts`.

The developers provide a patch by changing trait of `Copy` to `Pod`, which can make sure `T` should be plain data. This was patched in the latest version of [master](https://github.com/FyroxEngine/Fyrox/blob/3f9ad6f9667047dac051b0e97d544e5b38e5ae72/fyrox-core/src/lib.rs#L351-L360) branch, but still not on the latest release (0.28.1).

Patch / fix

  • crates.io fyrox-core 0.36, 0.36.0

Is GHSA-h7h7-6mx3-r89v 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 fyrox-core
>=0.28.1, <0.36
>=0.0.0-0, <0.36.0
0.36
0.36.0

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.