Arawoof06 opened a new pull request, #55290: URL: https://github.com/apache/arrow/pull/55290
### 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](https://arrow.apache.org/docs/dev/developers/overview.html#ai-generated-code), please disclose below whether and how AI was used in this PR. **PR code and description written by:** - [x] Human - [x] AI **Reviewed before submission by:** - [x] Human - [ ] AI - [ ] Not reviewed -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
