Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
Rand library can cause unexpected behavior with custom loggers
GHSA-cq8v-f236-94qc
Summary
The Rand library may cause unexpected behavior in certain situations. This can happen when a custom logger is used with the Rand library, and the logger tries to reseed the random number generator while also accessing certain Rand methods. This can lead to unpredictable behavior in optimized builds. If you're using a custom logger with Rand, you should upgrade to a version of Rand that is not affected.
What to do
- Update rand to version 0.9.3.
- Update rand to version 0.10.1.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| rust | – | rand |
>= 0.7.0, < 0.9.3 0.10.0 Fix: upgrade to 0.9.3
|
Original title
Rand is unsound with a custom logger using rand::rng()
Original description
It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
- The `log` and `thread_rng` features are enabled
- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
Affected versions of `rand` are `>= 0.7, < 0.9.3` and `0.10.0`.
- The `log` and `thread_rng` features are enabled
- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
Affected versions of `rand` are `>= 0.7, < 0.9.3` and `0.10.0`.
Vulnerability type
CWE-20
Improper Input Validation
Published: 14 Apr 2026 · Updated: 14 Apr 2026 · First seen: 14 Apr 2026