MINOR: [C++] Reject negative array offset in ArrayData validation

[Nayana-Naik73]

Rationale for this change

ValidateArrayImpl::ValidateLayout rejects a negative array length but never checks the offset. Every minimum buffer-size check below it is computed from length + offset, so a negative offset that cancels the length drives that sum to 0 and lets zero-sized or too-small buffers pass validation.

A negative offset reaches ArrayData through the C Data Interface: ArrayImporter copies the producer-supplied offset straight into the array and derives each buffer's expected size as length + offset. ValidateFull() is the documented way for a consumer to vet an imported array from an untrusted producer. With offset = -length and a short values buffer, Validate() and ValidateFull() both return OK, and reading the array afterwards addresses before the buffer:

    #0 arrow::NumericArray<arrow::Int32Type>::Value(long long) const array_primitive.h:121

raw_values_[offset + i] with offset = -1000 lands far outside the allocation (an out-of-bounds read, confirmed under ASan).

What changes are included in this PR?

Add an offset < 0 check next to the existing length < 0 check in ValidateLayout. Because validation recurses into child data, the single check covers every array and child.

Are these changes tested?

Yes. A negative-offset case is added to the ValidateBuffersPrimitive test. It fails on the current tree (Validate() returns OK) and passes with the fix; both the fix and the test were exercised under an ASan/UBSan build with the full arrow-array-test suite green.

Are there any user-facing changes?

Array::Validate() and Array::ValidateFull() now return Status::Invalid for an array whose offset is negative. No valid array produces a negative offset, so valid inputs are unaffected.

[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