kandarpck opened a new issue, #11954:
URL: https://github.com/apache/arrow-rs/issues/11954
### Describe the bug
`ParquetMetaDataReader::decode_metadata` reserves capacity from two counts
read from the footer before checking that the input can hold them. A corrupt
footer that claims about 2^31 entries makes the process abort on a failed
allocation instead of returning an error.
1. Row groups, `file/metadata/thrift/mod.rs` (59.3.1, line 815):
`Vec::with_capacity(list_ident.size as usize)`. `read_thrift_vec` already
guards the same pattern ("Thrift list size {} exceeds remaining input length
{}", `parquet_thrift.rs:739`), but this call site does not.
2. `SchemaElement.num_children`, `schema/types.rs` (59.3.1, line 1403):
`Vec::with_capacity(usize::try_from(n)?)`, where `n` is not bounded by
the number of schema elements.
Also present in 59.3.2.
### To Reproduce
For case 1, decode this 17-byte `FileMetaData` (Thrift compact): version 1,
a one-element schema, `num_rows` 0, then `row_groups` as a list header claiming
2147483647 structs:
`15 02 19 1C 48 01 72 00 16 00 19 FC FF FF FF FF 07`
`ParquetMetaDataReader::decode_metadata(&bytes)` asks for about 206 GB and
the process aborts.
### Expected behavior
An `Err(ParquetError)` in both cases: bound the row-group count by
`prot.remaining_bytes()` as `read_thrift_vec` does, and reject `num_children`
greater than the number of schema elements.
### Additional context
While decoding footers received from another process - one bad footer causes
the reader to crash
--
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]
