hsdfat opened a new pull request, #12215: URL: https://github.com/apache/arrow-rs/pull/12215
# Which issue does this PR close? - Closes #12200 # Rationale for this change `ByteViewArrayDecoderPlain::read_impl` adds the page's `u32` length prefix to `start_offset` without an overflow check. On a 32-bit target (`wasm32`, `i686`) a corrupt length such as `0xFFFF_FFFC` wraps `end_offset` to a value below `start_offset`, the `end_offset > buf_len` check passes, and `buf.get_unchecked(start_offset..end_offset)` is called with an inverted range. #12179 fixed the same pattern in `skip`; `read` was left out. `ByteArrayDecoderPlain::read` has the same unchecked addition. It uses a checked slice, so there it is a panic rather than UB, but it is the same bug on the same input, so I fixed both. # What changes are included in this PR? Both `read` paths compute the end offset with `checked_add(..).filter(|&end| end <= buf.len())` and return the existing `EOF` error, the same form #12179 used for `skip`. # Are these changes tested? Yes, one unit test per decoder reads a page whose first length is `0xFFFF_FFFC` and expects an `EOF` error. On 64-bit the addition cannot wrap, so the tests pass there with and without the fix. I ran them on `i686-unknown-linux-gnu` (`cargo test -p parquet --lib --no-default-features --features arrow --target i686-unknown-linux-gnu`): - without the fix, debug: both tests panic with an add overflow at the changed lines; - without the fix, release: the offset decoder panics on the slice, and the view decoder returns `Ok` from the inverted range instead of an error; - with the fix: both pass. I did not run Miri (not available in my toolchain); CI runs it. # Are there any significant user-facing changes? No. A corrupt page that could panic or hit undefined behaviour on 32-bit targets now returns an error. --- AI disclosure: the patch and tests were drafted with AI assistance (Claude); I reviewed every line and ran fmt, clippy and the parquet array reader tests, plus the i686 runs above. -- 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]
