luffy-zh opened a new pull request, #2629:
URL: https://github.com/apache/orc/pull/2629
<!--
Thanks for sending a pull request! Here are some tips for you:
1. File a JIRA issue first and use it as a prefix of your PR title, e.g.,
`ORC-001: Fix ABC`.
2. Use your PR title to summarize what this PR proposes instead of
describing the problem.
3. Make PR title and description complete because these will be the
permanent commit log.
4. If possible, provide a concise and reproducible example to reproduce
the issue for a faster review.
5. If the PR is unfinished, use GitHub PR Draft feature.
-->
### What changes were proposed in this pull request?
<!--
Please clarify what changes you are proposing. The purpose of this section
is to outline the changes and how this PR fixes the issue.
If possible, please consider writing useful notes for better and faster
reviews in your PR. See the examples below.
1. If you refactor some codes with changing classes, showing the class
hierarchy will help reviewers.
2. If there is a discussion in the mailing list, please add the link.
-->
Added overflow-safe bounds checking in three locations in c++/src/Reader.cc
using __builtin_add_overflow to prevent integer overflow when parsing malformed
ORC files with extremely large length values in PostScript:
1. readMetadata() - Use __builtin_add_overflow to safely compute total
tail size (footerLength + metadataSize + postscriptLength + 1) before comparing
against fileLength
2. createReader() - Use __builtin_add_overflow to safely compute tailSize
(1 + postscriptLength + footerSize) before bounds validation
3. startNextStripe() - Use __builtin_add_overflow to safely sum stripe
length components (offset + indexLength + dataLength + footerLength) before
comparing against fileLength
### Why are the changes needed?
<!--
Please clarify why the changes are needed. For instance,
1. If you propose a new API, clarify the use case for a new API.
2. If you fix a bug, you can clarify why it is a bug.
-->
When an ORC file's PostScript is crafted with footer_length or
metadata_length set to UINT64_MAX, the bounds check using unsigned addition
(e.g.,
metadataSize + footerLength + postscriptLength_ + 1) can overflow and wrap
around to a small value, bypassing validation.
For example, given a 58-byte file with footerLength = UINT64_MAX,
metadataSize = 0, and postscriptLength_ = 23:
- The sum wraps to 23 (mod 2^64)
- The check 58 < 23 evaluates to false, allowing invalid offset calculation
- This can cause SIGBUS crash due to out-of-bounds memory access
Using __builtin_add_overflow (a GCC/Clang builtin) provides a standard,
efficient way to detect overflow without manual subtraction logic.
### How was this patch tested?
<!--
If tests were added, say they were added here. Please make sure to add some
test cases that check the changes thoroughly including negative and positive
cases if possible.
If it was tested in a way different from regular unit tests, please clarify
how you tested step by step, ideally copy and paste-able, so that other
reviewers can test and check, and descendants can verify in the future.
If tests were not added, please describe why they were not added and/or why
it was difficult to add.
-->
Added two unit tests in c++/test/TestReader.cc:
1. testMalformedFooterLengthOverflow - Constructs a minimal malformed ORC
file with footer_length = UINT64_MAX and verifies that createReader() throws
ParseError
2. testMalformedMetadataLengthOverflow - Constructs a malformed file with
metadata_length = UINT64_MAX and verifies ParseError is thrown
### Was this patch authored or co-authored using generative AI tooling?
<!--
If generative AI tooling has been used in the process of authoring this
patch, please include the
phrase: 'Generated-by: ' followed by the name of the tool and its version.
If no, write 'No'.
Please refer to the [ASF Generative Tooling
Guidance](https://www.apache.org/legal/generative-tooling.html) for details.
-->
Generated-by: Claude code
--
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]