Affected: crates.io: tracing

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)`][`std::mem::forget`], and then moves values out of those pointers using [`std::ptr::read`].

```rust // 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][`std::mem::forget`] 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 com…