[Nayana-Naik73]

Rationale for this change

UnionConverter::AppendValue in arrow/json/from_string.cc reads the type_id of each [type_id, value] pair as an int64, truncates it to int8 and uses it straight away as an index into type_id_to_child_num_, which only has max_type_code() + 1 entries. The -1 "not found" check runs after that lookup. So with dense_union({a: int8, b: bool}, {4, 8}), input [[100, 1]] reads past the end of the vector (ASan heap out-of-bounds read at from_string.cc:867), and [[-1, 1]] reads before its start. The garbage child number is then used to index child_converters_, and the code makes a virtual call through that shared_ptr. Ids above 127 also wrap: [[260, 1]] is currently accepted as type code 4.

What changes are included in this PR?

The int64 type_id is range-checked against the lookup table before the cast. Out-of-range ids get the same Invalid "type_id ... not found" error that unknown codes already get.

Are these changes tested?

Yes. TestDenseUnionFromString.Errors and TestSparseUnionFromString.Errors now cover -1, 100 and 260. On the unpatched code they trip UBSan/ASan, and with the fix they pass. The full arrow-json-test suite passes under an ASan/UBSan debug build.

Are there any user-facing changes?

ArrayFromJSONString, ScalarFromJSONString and ChunkedArrayFromJSONString now return Invalid for union type ids outside the type's codes. Before, these reads were out of bounds or wrapped to another type code.

This PR contains a "Critical Fix". A union type_id in the JSON input could cause an out-of-bounds read, followed by a virtual call through an out-of-bounds shared_ptr, in the public ArrayFromJSONString / ScalarFromJSONString helpers.

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