[egiurleo]

Motivation

pm_string_query_local, pm_string_query_constant, and pm_string_query_method_name all share pm_slice_type. After it scans the identifier, it checks for a trailing !, ?, or =. When the identifier runs to the end of the slice, that check reads *source with source == end, which is one byte past the input.

Prism::StringQuery never sees this, because Ruby strings always have a readable byte after their contents. Callers that pass a slice of a larger buffer don't have that guarantee, including C callers and the Rust StringQuery API. It shows up in two ways:

• Wrong answers. StringQuery::new(&b"a!"[..1]).is_local() returns Ok(false), because the byte after the slice happens to be !.
• Crashes. If the slice ends right before an unmapped page, the read faults.

Since StringQuery is a safe Rust API, this is also a soundness bug. It's present in v2.1.0 and earlier.

Implementation

Check source < end before reading the suffix character.

Tests

Both new tests query a slice whose next byte is !, ?, or =. They fail without the fix and pass with it.

• test_does_not_read_past_slice in test/prism/ruby/string_query_test.rb calls the C functions directly through FFI. It only runs with the FFI backend, since the C extension always passes whole Ruby strings.
• subslice_test in rust/ruby-prism/src/string_query.rs covers the Rust StringQuery API, once per query type.

I also checked by hand with a small C program that places a one-byte name right before a guard page. It crashes all three APIs before the fix and returns the correct answers after.

[kddnewton]

Hi @egiurleo!