matanper opened a new issue, #69863: URL: https://github.com/apache/doris/issues/69863
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Version 4.1.4 (cloud mode, packed files). master is the same: `be/src/io/fs/packed_file_reader.cpp:54`: ```cpp size_t max_read = std::min(result.get_size(), static_cast<size_t>(_file_size - offset)); ``` ### Description `PackedFileReader::read_at_impl` reads a slice of a packed file. `_file_size` is `int64_t` and `offset` is `size_t`, so `_file_size - offset` is computed in unsigned arithmetic. When `offset` is past the end of the slice, it wraps to a huge value, `max_read` becomes the full request size, and the read returns the bytes that follow the slice in the packed file. Those belong to another file, so the caller gets silently wrong data instead of an error (for example, a corrupt-looking index or segment page that is actually a neighbour's bytes). ### Solution Check the offset before computing the length and return `Status::Corruption` (naming the slice, its size and offset in the packed file) when `offset > _file_size` (or `_file_size < 0`); compute the remaining length as `static_cast<size_t>(_file_size) - offset`. ### How to Reproduce? Unit test: open a `PackedFileReader` over a slice of size N inside a larger packed file and call `read_at(N + k, ...)`; it returns bytes from the next slice instead of failing. ### Anything Else? An out-of-range offset normally means wrong metadata somewhere upstream of the reader, which is exactly when an error is more useful than another file's bytes. ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
