PlenoraETL opened a new issue, #10575:
URL: https://github.com/apache/arrow-rs/issues/10575
### Describe the bug
`arrow-ipc`
`convert::fb_to_schema` is infallible and panics on schema messages that the
FlatBuffer decoder itself accepts. Every reader path calls it, so there is no
way to read Arrow IPC without exposing the process to an abort on untrusted
input.
The immediate case is `let c_fields = fb.fields().unwrap();` — `fields` is an
optional field in the FlatBuffer schema, and a message without it aborts the
process.
Reproduced on 59.1.0. The code is unchanged on `main` as of 2026-08-07
(`convert.rs:196`).
### To Reproduce
Only dependency is `arrow-ipc = "=59.1.0"`:
```rust
use arrow_ipc::reader::StreamReader;
fn main() {
// 81 bytes: an IPC stream whose schema message has no `fields` vector.
let bytes: &[u8] = &[
0x2c, 0x00, 0x00, 0x00, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x08,
0x00, 0x04, 0x00,
0x00, 0x00, 0x00, 0x00, 0x3d, 0x08, 0x00, 0x22, 0x00, 0x00, 0x14,
0x00, 0x00, 0x00,
0x08, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00,
0x00, 0x00, 0x60,
0x00, 0x00, 0x2a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3f, 0x00, 0x00,
0x00, 0x00, 0x08,
0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
];
match StreamReader::try_new(bytes, None) {
Ok(_) => println!("accepted"),
Err(error) => println!("Err (expected): {error}"),
}
}
```
Output:
```
thread 'main' panicked at arrow-ipc-59.1.0/src/convert.rs:198:32:
called `Option::unwrap()` on a `None` value
```
### Expected behavior
`StreamReader::try_new` returns `Result`, so malformed input should surface
as
`Err(ArrowError::ParseError(..))` rather than aborting the process.
---
Additional context
Fuzzing a pipeline that reads Arrow IPC and Parquet surfaced three distinct
panic paths in this function family:
| site | trigger |
|---|---|
| `convert.rs:198` | `unwrap()` on a missing `fields` vector |
| `convert.rs:354` | `FloatingPoint type with precision of <UNKNOWN n> not
supported` |
| `convert.rs:514` | `not implemented: Type NONE not supported` |
`convert.rs` currently has ~20 `panic!`/`unimplemented!` and 31 `unwrap()`
reachable from decoder input.
Two things make this easy to hit unknowingly:
1. The `try_*` wrappers are only partially fallible.
`try_schema_from_flatbuffer_bytes` and `try_schema_from_ipc_buffer` handle
outer parse failures, then call `.map(fb_to_schema)` — the `try_` prefix
does not cover schema conversion.
2. Parquet is affected too. A Parquet footer may carry the `ARROW:schema`
key,
which `ParquetRecordBatchReaderBuilder::try_new` deserialises through this
path, so reading an untrusted `.parquet` can abort the process.
Possible non-breaking fix: `get_data_type` is `pub(crate)`, so its signature
is
free to change. A `Result`-returning `get_data_type`, a new public
`try_fb_to_schema`, and readers switched to it would leave the public
`fb_to_schema` intact for compatibility. Happy to open a PR along those lines
if the approach sounds right.
### Additional context
_No response_
--
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]
