GH-50462: [C++][Gandiva] fix out-of-bounds read in translate_utf8_utf8_utf8#50463
GH-50462: [C++][Gandiva] fix out-of-bounds read in translate_utf8_utf8_utf8#50463Arawoof06 wants to merge 2 commits into
Conversation
|
|
|
|
github-actions
Bot
added
Component: C++
Component: Gandiva
awaiting review
|
@dmitry-chirkov-dremio @lriggs @akravchukdremio @xxlaykxx Could you review this? |
| EXPECT_STREQ(result, ""); | ||
| EXPECT_THAT(ctx.get_error(), | ||
| ::testing::HasSubstr("Would overflow maximum output size")); | ||
|
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
github-actions
Bot
added
awaiting committer review
3 participants
Rationale for this change
The multi-byte branch of
translate_utf8_utf8_utf8(taken whenever the input, FROM, or TO contains a byte > 127) readsgdv_fn_utf8_char_lengthon a lead byte and then builds astd::stringof 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 (thefrom_for == from_lencheck ran after the read), and a truncated glyph in TO reads past TO. All three are reachable from the SQLtranslate(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
translatereachable from user-supplied string data.