From 0dc8063289772676fd281e514b58ea68a1dc5752 Mon Sep 17 00:00:00 2001 From: Georgios Androutsopoulos Date: Thu, 14 Aug 2025 15:42:39 -0400 Subject: [PATCH] HBOF due to user-defined implementations of scratchpad::Tracking (add note) --- crates/scratchpad/RUSTSEC-0000-0000.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/crates/scratchpad/RUSTSEC-0000-0000.md b/crates/scratchpad/RUSTSEC-0000-0000.md index 0664232b..63beff89 100644 --- a/crates/scratchpad/RUSTSEC-0000-0000.md +++ b/crates/scratchpad/RUSTSEC-0000-0000.md @@ -20,4 +20,6 @@ patched = [] 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. \ No newline at end of file +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](https://github.com/okready/scratchpad/commit/957dee1a3902f48600b06910e8e0b1d5ee7dab83), the crate is in maintenance mode awaiting a cleanup that will reduce the area of unsafe code.