Out-of-bounds read in `Log2Cache::nlog2n()`, `nlog2n_difference()` and `plog2p()`
`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.
- Products
- dahl-salso
- Affected versions
- Not specified
- Fixed versions
- 0.7.0
- CVEs
- Not specified
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 1 Nov 2026, 14:47 UTC · Revision 1
Source evidence
Out-of-bounds read in `Log2Cache::nlog2n()`, `nlog2n_difference()` and `plog2p()`
core-osv · Original sourcePublished 22 Oct 2026, 12:00 UTC
`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.
osv:RUSTSEC-2026-0411
dahl-salso
Fixed versions: 0.7.0
Complete source record
{
"id": "927db6d03653616e1d5a6c5587452e10dfd76d2d78ba06e492e6ed42c6948272",
"url": "https://osv.dev/vulnerability/RUSTSEC-2026-0411",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Out-of-bounds read in `Log2Cache::nlog2n()`, `nlog2n_difference()` and `plog2p()`",
"summary": "`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.",
"evidence": "osv:RUSTSEC-2026-0411",
"products": [
{
"name": {
"value": "dahl-salso",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "0.7.0",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "RUSTSEC-2026-0411",
"aliases": [
"RUSTSEC-2026-0411"
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "0.7.0"
}
]
}
],
"package": {
"name": "dahl-salso",
"purl": "pkg:cargo/dahl-salso",
"ecosystem": "crates.io"
},
"database_specific": {
"cvss": null,
"source": "https://github.com/rustsec/advisory-db/blob/osv/crates/RUSTSEC-2026-0411.json",
"categories": [
"memory-corruption",
"memory-exposure"
],
"informational": "unsound"
},
"ecosystem_specific": {
"affects": {
"os": [],
"arch": [],
"functions": []
},
"affected_functions": null
}
}
],
"modified": "2026-10-26T14:00:05.091904359Z",
"provider": "osv",
"references": [
"https://crates.io/crates/dahl-salso",
"https://rustsec.org/advisories/RUSTSEC-2026-0411.html",
"https://github.com/dbdahl/rust-dahl-salso/issues/2"
],
"provider_metadata": {
"license": "CC0-1.0"
}
},
"related_cves": [],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 454193,
"published_at": "2026-10-22T12:00:00+00:00"
}