Skip to content

fix(deps): update rand 0.9.2 → 0.9.3 (GHSA-cq8v-f236-94qc)#1396

Open
Copilot wants to merge 3 commits intomainfrom
copilot/fix-rand-unsound-logger-issue
Open

fix(deps): update rand 0.9.2 → 0.9.3 (GHSA-cq8v-f236-94qc)#1396
Copilot wants to merge 3 commits intomainfrom
copilot/fix-rand-unsound-logger-issue

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Apr 29, 2026

rand 0.9.2 is unsound when a custom logger calls rand::rng() during reseeding, creating aliased mutable references (UB under Stacked Borrows). Patched in 0.9.3.

Changes

  • Cargo.lock: bumped transitive rand 0.9.20.9.3 via cargo update -p rand@0.9.2 --precise 0.9.3

Reachability Assessment

Not reachable — high confidence.

rand 0.9.x is purely transitive here (via opentelemetry_sdk v0.31.0 and regorus v0.9.1); the workspace directly depends on rand 0.10.x. The two custom log::Log implementations in the codebase (TestLog, MemLog in crates/weaver_common/src/lib.rs) never call rand::rng() — they only buffer records in memory. The aliased-mutable-ref condition cannot be triggered.

Update is to clear the advisory scanner rather than mitigate an active risk.

Original prompt

This section details the Dependabot vulnerability alert you should resolve

<alert_title>Rand is unsound with a custom logger using rand::rng()</alert_title>
<alert_description>It has been reported (by @lopopolo) that the rand library is unsound (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 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, the behaviour of optimized builds is hard to predict.</alert_description>

low
GHSA-cq8v-f236-94qc
rand
rust
<vulnerable_versions>= 0.9.2</vulnerable_versions>
<patched_version>0.9.3</patched_version>
<manifest_path>Cargo.lock</manifest_path>

https://github.com/rust-random/rand/pull/1763 https://rustsec.org/advisories/RUSTSEC-2026-0097.html https://github.com/advisories/GHSA-cq8v-f236-94qc

<agent_instructions>Can you determine if this applies to weaver?

Please include links to actual code where custom loggers and RNG are used together.</agent_instructions>

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest (e.g. package.json, Gemfile, pyproject.toml) caps the version below the fix, update the constraint first. For transitive dependencies, determine whether it is simpler to update the direct dependency that pulls in the vulnerable package or to update the transitive dependency directly, and choose the least disruptive approach. If upgrading to fix the vulnerability forces a major version bump or known breaking changes, review the changelog or release notes, then audit the codebase for usage of affected APIs and fix any breaking changes that are found. If the package manager fails to resolve dependencies (e.g. peer dependency conflicts, incompatible engine constraints), document the error in the PR description rather than attempting increasing...

Copilot AI changed the title [WIP] Fix rand unsound issue with custom logger fix(deps): update rand 0.9.2 → 0.9.3 (GHSA-cq8v-f236-94qc) Apr 29, 2026
Copilot AI requested a review from jsuereth April 29, 2026 18:07
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 30, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.4%. Comparing base (69132ef) to head (69f9f9f).

Additional details and impacted files
@@           Coverage Diff           @@
##            main   #1396     +/-   ##
=======================================
- Coverage   82.4%   82.4%   -0.1%     
=======================================
  Files        120     120             
  Lines      10092   10092             
=======================================
- Hits        8320    8318      -2     
- Misses      1772    1774      +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@jsuereth jsuereth marked this pull request as ready for review May 1, 2026 13:27
@jsuereth jsuereth requested a review from a team as a code owner May 1, 2026 13:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants