GH-50462: [C++][Gandiva] fix out-of-bounds read in translate_utf8_utf8_utf8

[Arawoof06]

Rationale for this change

The multi-byte branch of translate_utf8_utf8_utf8 (taken whenever the input, FROM, or TO contains a byte > 127) reads gdv_fn_utf8_char_length on a lead byte and then builds a std::string of that width from the buffer without checking how many bytes remain. A truncated trailing glyph in the input reads past IN, a multi-byte input character missing from FROM reads one byte past FROM at the end-of-list sentinel (the from_for == from_len check ran after the read), and a truncated glyph in TO reads past TO. All three are reachable from the SQL translate(in, from, to) call on truncated column data.

What changes are included in this PR?

Clamp each utf8 character width to the bytes left in its buffer before copying, consuming a single byte on a truncated or invalid lead byte (which also stops a zero-width advance from looping forever), and move the FROM end-of-list check ahead of the read so the sentinel iteration no longer touches from[from_len]. Valid input keeps its existing grouping since the clamp only fires past the end.

Are these changes tested?

Yes. Added two cases to TestGdvFnStubs.TestTranslate: a truncated trailing glyph in the input, and a valid multi-byte input char absent from FROM. Both use exact-sized buffers so ASAN trips on the pre-patch over-read and passes after the fix.

Are there any user-facing changes?

No.

This PR contains a "Critical Fix". It fixes a heap out-of-bounds read (crash) in translate reachable from user-supplied string data.

• GitHub Issue: [C++][Gandiva] Out-of-bounds read in translate on truncated multi-byte input #50462

[github-actions]

⚠️ GitHub issue #50462 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #50462 has no components, please add labels for components.

[kou]

@dmitry-chirkov-dremio @lriggs @akravchukdremio @xxlaykxx Could you review this?

[dmitry-chirkov-dremio]

Nice fix.

I think the logic change is sound: moving the from_for == from_len check ahead of the read closes the one-byte over-read, and clamping invalid/truncated UTF-8 widths to 1 avoids both OOB reads and zero-width infinite loops.

The one thing still missing is a regression test for the to side, since this patch also changes len_char_to handling. Please add a case where to ends in a truncated or invalid multibyte lead byte so the third safety fix is covered too.

[Arawoof06]

Added it. New case maps a matched input char to a to that ends in a truncated 0xE2 lead byte, so the pre-patch build over-reads TO by 2 bytes (ASAN READ of size 3) and the clamp passes it through as the single byte. Covers the third fix now.

[dmitry-chirkov-dremio]

LGTM