[mliem2k]

PDBInformation::stream_names indexed the names block with the name_offset values taken verbatim from the names map, without checking them against names_buf.len():

let name = ParseBuffer::from(&names_buf[name_offset..]).parse_cstring()?;

A names-map entry with name_offset = 0xFFFF0000 therefore panicked on the slice range check, in release too, before any DBI or module data was read:

thread 'main' panicked at pdb-0.8.0/src/pdbi.rs:140:52:
range start index 4294901760 out of range for slice of length 5

The loop already returns Error::UnexpectedEof for a name that is not NUL-terminated, so an offset past the end of the block now returns the same error instead of panicking:

let name = ParseBuffer::from(names_buf.get(name_offset..).ok_or(Error::UnexpectedEof)?)
    .parse_cstring()?;

Tests

Added two tests to tests/pdb_information.rs that build a 4 KiB MSF in memory, with the PDB Information stream holding one named stream and a 5-byte names block:

• stream_names_reads_a_name_offset_inside_the_names_block uses name_offset = 2 and asserts the name is "b". It pins that the fixture is otherwise valid, so the error in the next test comes from the offset alone.
• stream_names_rejects_a_name_offset_past_the_names_block uses name_offset = 0xFFFF0000 and asserts stream_names() returns an error.

Before the fix the second test panics with the message above; after it, both pass:

running 3 tests
test stream_names_reads_a_name_offset_inside_the_names_block ... ok
test stream_names_rejects_a_name_offset_past_the_names_block ... ok
test pdb_info ... ok

cargo test passes 83 lib tests and the other integration tests. tests/id_information.rs fails on this checkout because it needs scripts/download to fetch its fixture; that is unrelated to this change. cargo fmt --check is clean, and cargo clippy --all-features --workspace --tests --examples -- -D clippy::all reports nothing in src/pdbi.rs or the new test (the 14 errors it prints are pre-existing lints in dbi.rs, modi/, msf/ and tpi/).

Fixes #171.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.