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.