Out-of-bounds read in Log2Cache::nlog2n(), nlog2n_difference() and plog2p()

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

not scored

EPSS

No dated EPSS signal available.

As published by the source; long descriptions are shortened.

`Log2Cache::new(n)` fills its three tables with entries for `0..=n`, but the three accessor methods index those tables with `get_unchecked` on a value the caller supplies. Nothing bounds the argument and nothing documents a bound, so any value above the `n` the cache was built with reads past the end of the vector. `CountType` is `u32`, so the read can land up to `u32::MAX` elements away, and `plog2p()` returns the value it read, disclosing whatever lies there. For example, `Log2Cache::new(4)` builds tables holding 5 entries (indices 0,1,2,3,4). Then `cache.nlog2n(60000)` reads index 60000, far outside the allocation. Under AddressSanitizer this faults with `SEGV`; Miri reports it as undefined behavior at `src/log2cache.rs:42`. `nlog2n_difference()` is off by one further: in the affected versions `new(n)` pushes `n` entries into that table rather than `n + 1`, so even `nlog2n_difference(n)` is out of bounds. This can be triggered through safe public APIs — `Log2Cache::new()` and any…

Published by the source

22 Oct 2026, 12:00 UTC

Last modified by the source

26 Oct 2026, 14:00 UTC

Source last checked

27 Oct 2026, 06:25 UTC

1. Revision 1 · created · 27 Oct 2026

   Published from osv record RUSTSEC-2026-0411

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: rustsec-2026-0411

Advisory: Out-of-bounds read in `Log2Cache::nlog2n()`, `nlog2n_difference()` and `plog2p()`
IDs: rustsec-2026-0411
Record: https://patchnext.com/advisories/rustsec-2026-0411 (revision 1, source checked 27 Oct 2026, 06:25 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Unrated
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: dahl-salso 0.7.0. A vendor fix does not mean a deployment is fixed.

## Affected components
- crates.io dahl-salso: affected >= 0.0.0-0, < 0.7.0; fixed in 0.7.0

## Suggested inspection (read-only)
- crates.io dahl-salso: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on dahl-salso.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://osv.dev/vulnerability/RUSTSEC-2026-0411 (OSV record RUSTSEC-2026-0411 lists affected ranges: crates.io dahl-salso >=0.0.0-0 <0.7.0 (fixed))

Commands are suggestions: review each one before running it.