[Arawoof06]

Rationale for this change

The padding kernels (ascii_lpad/ascii_rpad/ascii_center, utf8_lpad/utf8_rpad/utf8_center and utf8_zero_fill) preallocate the output values buffer from MaxCodeunits, which returns input_ncodeunits + k * ninputs * options_.width with no handling of the width's range. Transform copies a string unchanged whenever it is already at least width characters wide, so the buffer must always hold the whole input.

A negative width breaks that. ascii_rpad with width=-8 on 64 eight-byte strings sizes the buffer at 0 bytes and then copies 512 bytes into it (ASAN reports a global-buffer-overflow write into the zero-size allocation). Smaller inputs with a negative width fail with "Negative buffer resize" instead of returning the strings unchanged. A very large width has the same effect through signed overflow: utf8_lpad with width=1<<62 wraps 4 * ninputs * width to 0, and the kernel then writes padding far past the allocation (ASAN heap-buffer-overflow).

What changes are included in this PR?

A small PadMaxCodeunits helper in scalar_string_internal.h used by all three pad transforms. It treats a negative width as 0, which matches what Transform already does with it, and computes the bound with MultiplyWithOverflow/AddWithOverflow. If the bound doesn't fit in int64_t it saturates, so the existing output capacity check or the allocation fails with an error instead of producing an undersized buffer.

Are these changes tested?

Yes. PadAscii, PadUTF8 and UTF8ZeroFill now check that a negative width returns the input unchanged and that a width whose size estimate overflows returns an error. On the unpatched tree, the negative width cases fail with "Negative buffer resize" and the overflow case aborts under ASAN with a heap-buffer-overflow. With the patch, arrow-compute-scalar-type-test passes (Debug + ASAN, utf8 and large_utf8).

Are there any user-facing changes?

A negative width now leaves strings unchanged for every input size instead of either erroring or corrupting memory. A width too large to size the output now returns an error. Behavior for ordinary widths is unchanged.

This PR contains a "Critical Fix". A negative or very large PadOptions/ZeroFillOptions width makes the pad kernels write past their output buffer.

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.

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 8 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