RUSTSEC-2023-0078: Potential stack use-after-free in `Instrumented::into_inner`

What to do

1. See which version you have: cargo tree -i tracing (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p tracing. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example tracing = "0.1.40") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

The implementation of the Instrumented::into_inner method in affected versions of this crate contains undefined behavior due to incorrect use of std::mem::forget The function creates *const pointers to self, calls mem::forget(self), and then moves values out of those pointers using std::ptr::read.

// To manually destructure `Instrumented` without `Drop`, we
// move it into a ManuallyDrop and use pointers to its fields
let span: *const Span = &this.span;
let inner: *const ManuallyDrop<T> = &this.inner;
mem::forget(self);
// SAFETY: Those pointers are valid for reads, because `Drop` didn't
//         run, and properly aligned, because `Instrumented` isn't
//         `#[repr(packed)]`.
let _span = unsafe { span.read() };
let inner = unsafe { inner.read() };

However, the mem::forget documentation states:

> Any resources the value manages, such as heap memory or a file handle, will > linger forever in an unreachable state. **However, it does not guarantee that > pointers to this memory will remain valid.**

This means that these pointers are no longer valid. This could result in a stack use-after-free if LLVM chooses to reuse self's stack slot for a rebinding after the call to std::mem::forget.

This undefined behavior has not been observed to cause miscompilation as of Rust 1.73.0. However, any use of this method with the affected versions of tracing are unsound.

The flaw was corrected in commit 20a1762 (PR #2765) by replacing the use of std::mem::forget with std::mem::ManuallyDrop, ensuring that the stack slot is not reused and the pointers remain valid when they are read. The fix is published in tracing v0.1.40. Affected versions have been yanked from crates.io.

Thanks to Taylor Cramer and Manish Goregaokar for finding and correcting this issue!

References

• Package: crates.io/crates/tracing
• Advisory: rustsec.org/advisories/RUSTSEC-2023-0078.html
• Web: github.com/tokio-rs/tracing/pull/2765

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