GHSA-xfhw-6mc4-mgxf json
crayon: ObjectPool creates uninitialized memory when freeing objects
published 2y ago modified 2y ago also RUSTSEC-2024-0018
- cvss
- 7.5
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
As of version 0.6.0, the ObjectPool explicitly creates an uninitialized instance of its type parameter when it attempts to free an object, and swaps it into the storage. This causes instant undefined behavior due to reading the uninitialized memory in order to write it to the pool storage.
Extremely basic usage of the crate can trigger this issue, e.g. this code from a doctest:
```rust use crayon::prelude::*; application::oneshot().unwrap();
let mut params = MeshParams::default();
let mesh = video::create_mesh(params, None).unwrap();
// Deletes the mesh object. video::delete_mesh(mesh); // <-- UB ```
The Clippy warning for this code was silenced in commit c2fde19caf6149d91faa504263f0bc5cafc35de5.
Discovered via https://asan.saethlin.dev/ub?crate=crayon&version=0.7.1
Patch / fix
Is GHSA-xfhw-6mc4-mgxf 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 FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 7.5 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | crayon | >=0.6.0, <=0.7.1 >=0.6.0 |
no fix listed |
Classification
- Weakness
-
- CWE-908 Use of Uninitialized Resource
References
Sources
- GitHub Advisory GHSA-xfhw-6mc4-mgxf
- OSV RUSTSEC-2024-0018
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.