RUSTSEC-2026-0411None▾ SunlitOut-of-bounds read in `Log2Cache::nlog2n()`, `nlog2n_difference()` and `plog2p()`
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
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.
dahl-salso >= 0.0.0-0, < 0.7.0Upgrade to a patched release:
dahl-salso 0.7.0