Nayana-Naik73 opened a new pull request, #54510:
URL: https://github.com/apache/arrow/pull/54510
### Rationale for this change
`SliceBytesTransform::MaxCodeunits` (`binary_slice`) and
`SliceCodeunitsTransform::MaxCodeunits` (`utf8_slice_codeunits`) size the
output buffer from `(stop - start + step - 1) / step` using raw `int64_t`
arithmetic on the user-supplied `SliceOptions`, whose `start`, `stop` and
`step` are unbounded. A large `stop` (binary) or a large `step`/very negative
`start` (utf8, where only `stop` is clamped) overflows the
addition/subtraction, so `max_slice_bytes` wraps negative,
`std::max<int64_t>(0, .)` collapses it to `0`, and the kernel allocates a
zero-length output buffer. `Transform` then writes the real slice into that
buffer, an out-of-bounds write.
This is reachable from a default pyarrow call: `pc.binary_slice(arr, 0,
step=2)` leaves `stop` at `sys.maxsize` (`INT64_MAX`), so `stop - start + step
- 1` is `INT64_MAX + 1`. Under a UBSan build the subtraction/addition is
flagged as signed-integer-overflow; under ASan the subsequent copy is a
heap-buffer-overflow.
```
scalar_string_ascii.cc:2645:53: runtime error: signed integer overflow:
9223372036854775807 + 2 cannot be represented in type 'int64_t'
```
### What changes are included in this PR?
Both `MaxCodeunits` overrides compute the span and the final `ninputs *
estimate` product with
`SubtractWithOverflow`/`AddWithOverflow`/`MultiplyWithOverflow` and fall back
to the input length on overflow. The input length is always a valid upper bound
on the sliced output, so this matches the existing mismatched-sign fallback and
leaves the value bit-identical for every non-overflowing input.
### Are these changes tested?
Yes. `SliceBytesOverflow` and `SliceCodeunitsOverflow` in
`scalar_string_test.cc` exercise `INT64_MAX`/`INT64_MIN` options (including the
default pyarrow `stop`). They abort under UBSan/ASan on the current tree and
pass with the fix; the full `arrow-compute-scalar-type-test` suite stays green
(352 tests).
### Are there any user-facing changes?
No. Valid inputs produce the same results; only the pathological overflow
case now allocates the safe worst-case buffer instead of corrupting memory.
**This PR contains a "Critical Fix".** An overflow in the slice output-size
computation led to a zero-length allocation followed by an out-of-bounds write
of the sliced bytes.
### Was AI used for 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]
