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]

Reply via email to