Skip to content
Fencer Intel
medium —

GHSA-8f24-6m29-wm2r json

use-after-free in tracing

published 3y ago modified 2y ago also RUSTSEC-2023-0078

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

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 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!

[`Instrumented::into_inner`]: https://docs.rs/tracing/latest/tracing/instrument/struct.Instrumented.html#method.into_inner [`std::mem::forget`]: https://doc.rust-lang.org/std/mem/fn.forget.html [`std::ptr::read`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.read-1 [20a1762]: https://github.com/tokio-rs/tracing/commit/20a1762b3fd5f1fafead198fd18e469c68683721 [PR #2765]: https://github.com/tokio-rs/tracing/pull/2765 [v0.1.40]: https://crates.io/crates/tracing/0.1.40 [Taylor Cramer]: https://github.com/cramertj [Manish Goregaokar]: https://github.com/manishearth

Patch / fix

Is GHSA-8f24-6m29-wm2r in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
crates.io tracing
>=0.1.38, <0.1.40
>=0.1.38-0, <0.1.40
0.1.40

Classification

Weakness

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.