RUSTSEC-2025-0049: User-defined implementations of the safe trait scratchpad::Tracking can cause heap buffer overflows

What to do

1. Find who pulls it in: cargo tree -i scratchpad.
2. Avoid the affected API (scratchpad::Tracking::get, scratchpad::Tracking::set), or replace the crate.

Details from the advisory

The get and set methods of the public trait scratchpad::Tracking interact with unsafe code regions in the crate, and they influence the computation of addresses returned as raw pointers. However, the trait itself is not marked as unsafe, meaning users may provide custom implementations under the assumption that the crate upholds all safety guarantees.

This becomes problematic because even safe implementations of get and set-written without using any unsafe code-can still result in ill-formed raw pointers. These pointers may later be dereferenced within safe APIs of the crate (e.g., marker::MarkerBack::allocate_slice_copy), potentially leading to arbitrary memory access or heap buffer overflows.

According to the penultimate commit, the crate is in maintenance mode awaiting a cleanup that will reduce the area of unsafe code. Note that the last commits to the repository are from 4 years ago.

References

• Package: crates.io/crates/scratchpad
• Advisory: rustsec.org/advisories/RUSTSEC-2025-0049.html
• Report: github.com/okready/scratchpad/issues/2

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 scratchpad

• Vulnerability CriticalRUSTSEC-2021-0030 · 2021-02-18move_elements can double-free objects on panic

Full security history of scratchpad