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
- crates.io tracing 0.1.40
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 FencerAffected 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
-
- CWE-416 Use After Free
References
-
github.com
/tokio-rs/tracing/pull/2765
web
-
github.com
/tokio-rs/tracing/commit/20a1762b3fd5f1fafead198fd18e469c68683721
web
-
github.com
/tokio-rs/tracing
package
-
github.com
/tokio-rs/tracing/releases/tag/tracing-0.1.40
web
-
rustsec.org
/advisories/RUSTSEC-2023-0078.html
web, advisory
-
crates.io
/crates/tracing
package
Sources
- GitHub Advisory GHSA-8f24-6m29-wm2r
- OSV RUSTSEC-2023-0078
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.