Skip to main content
VulnerabilityPublished Updated

Dahl salso: Out-of-bounds read

Affects dahl-salsoSource GCVE Database

0
Severity
Unrated

Rated by Threat Radar

Patch
Available – fixed in 0.7.0

Data as of 26 Oct 2026, 16:13 UTC

What to do

Upgrade dahl-salso to 0.7.0.

Affected software

ProductAffectedFixed in
crates.iodahl-salsopkg:cargo/dahl-salsoOther threatsAffected
  • >=0.0.0-0 <0.7.0
Fixed in
  • 0.7.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

`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 of `nlog2n()`, `nlog2n_difference()` and `plog2p()` — with no `unsafe` required from the caller.

References

Community reviews

Loading reviews…