RUSTSEC-2024-0018: ObjectPool creates uninitialized memory when freeing objects

What to do

1. Find who pulls it in: cargo tree -i crayon.
2. Avoid the affected API (crayon::utils::object_pool::ObjectPool<H,T>::free), or replace the crate.

Details from the advisory

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:

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

References

• Package: crates.io/crates/crayon
• Advisory: rustsec.org/advisories/RUSTSEC-2024-0018.html
• Report: github.com/shawnscode/crayon/issues/109

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.

Other advisories for crayon

• Unsound HighRUSTSEC-2020-0037 · 2020-08-31Misbehaving `HandleLike` implementation can lead to memory safety violation

Full security history of crayon