[Nayana-Naik73]

Rationale for this change

ValidateArrayImpl::Visit(const FixedSizeListType&) requires the child values array to hold length * list_size elements, but FixedSizeListArray::value_offset(i) and the kernels address the child at (offset + i) * list_size. A fixed_size_list array with a non-zero offset and a child of exactly length * list_size elements passes Validate() and ValidateFull() and then reads up to offset * list_size elements past the end of the child. With offset = 100 over a 4-element int32 child, ValidateFull() returns OK and reading the first value is an ASan heap-buffer-overflow.

Arrays sliced by Arrow itself always satisfy the stronger bound, so this only matters for externally supplied ArrayData, e.g. an ArrowArray imported through the C Data Interface, where the offset comes from the producer and ValidateFull() is the check consumers rely on.

What changes are included in this PR?

The expected values length is computed from length + offset, the same bound the struct and sparse union checks already use. ValidateLayout has already rejected an overflowing length + offset by this point.

TestArrayImport.ListWithOffset had two fixed_size_list fixtures whose child length (9) was shorter than what the expected values read (12 elements). They only passed because the backing test buffer is 16 bytes. The child length is corrected to 12 and the expected values are unchanged.

Are these changes tested?

Yes. TestFixedSizeListArray.NotEnoughValues now covers an offset that fits and one that does not, and it fails without the fix. arrow-array-test, arrow-c-bridge-test and the rest of the C++ test suite (compute, IPC, Parquet, dataset) pass locally in an ASan debug build.

Are there any user-facing changes?

Fixed-size list arrays whose child is too short for their offset are now rejected by Validate()/ValidateFull().

This PR contains a "Critical Fix". ValidateFull() accepted fixed_size_list arrays that lead to out-of-bounds reads of the child array.

Was AI used for 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 converted to a draft because its title doesn't match Arrow's required format.

If this is not a minor PR, could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

After updating the title, you can mark the pull request as ready for review.

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[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