MINOR: [C++][Compute] Reject non-UTF-8 padding in utf8 pad kernels

[Nayana-Naik73]

Rationale for this change

utf8_lpad/utf8_rpad/utf8_center and utf8_zero_fill check that the padding is one codepoint with util::UTF8Length, which only counts non-continuation bytes and assumes valid UTF-8. A padding like "a" followed by any number of 0x80 bytes passes that check, but MaxCodeunits sizes the output as input_ncodeunits + 4 * ninputs * width (at most 4 bytes per codepoint) while Transform copies the whole padding string per pad. With padding = "a" + std::string(15, '\x80') and width = 100, ASan reports a heap-buffer-overflow write in Utf8PadTransform::Transform.

What changes are included in this PR?

The padding is required to be valid UTF-8 in both PreExec checks, so a padding that passes is at most 4 bytes. util::InitializeUTF8() is called first, as the cast kernels do, since ValidateUTF8 needs the lookup tables.

Are these changes tested?

Yes. Added a malformed padding case to PadUTF8 and UTF8ZeroFill in scalar_string_test.cc. Before the fix it overflows under ASan; with the fix arrow-compute-scalar-type-test passes (ASan Debug build).

Are there any user-facing changes?

Padding that is not valid UTF-8 is now rejected with the existing "Padding must be one codepoint" error instead of being accepted.

This PR contains a "Critical Fix". A malformed padding option caused an out-of-bounds write into the output data buffer of these kernels.

Was AI used for this PR?

In accordance to the AI generation guidelines, please disclose below whether and how AI was used in this PR.

This fix was found and prepared with AI assistance and reviewed by me before submitting.

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

[github-actions]

Thanks for opening a pull request!

This pull request has been automatically closed because you currently have 4 open pull requests, which is more than the limit of 3.

Due to the increase in pull requests opened by AI bots, and in order to keep the review queue manageable, Apache Arrow limits contributors without repository access to at most 3 concurrently open pull requests. This helps make sure each pull request gets the attention it needs and that work in progress does not go stale.

Once one of your other open pull requests has been merged or closed, you are welcome to reopen this one.

See also:

• Contribution Guidelines - Limit on concurrent pull requests
• Contribution Guidelines - Contributing Overview