You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Python] Several APIs segfault instead of rejecting arguments of the wrong type #51042
Several PyArrow APIs terminate the interpreter when an argument is not the documented Arrow wrapper type.
The native crash sites are different, but each case appears to continue after an Arrow object conversion or cast failed.
I found these cases while fuzzing Python C extension modules.
I tested None, bool, int, float, complex, str, bytes, bytearray, list, tuple, dict, set, object(), and an Arrow object of the wrong wrapper class in separate processes.
API
Accepted input
ParquetReadOptions(binary_type=...)
pyarrow.DataType, None
Sparse from_tensor()
pyarrow.Tensor
substrait.serialize_schema()
pyarrow.Schema
IndexOptions(...).serialize()
pyarrow.Scalar
Every tested value not listed as accepted for the corresponding API caused SIGSEGV.
For IndexOptions, the invalid value is accepted during construction and the crash occurs later in serialize().
ASan/UBSan result
I built PyArrow 25.0.0 from source with Clang 18 using ASan and UBSan instrumentation.
The first sanitizer failures were:
API
First native failure
ParquetReadOptions(binary_type=...)
member call on a null arrow::DataType at build/_dataset_parquet.cpp:19827
Sparse from_tensor()
reference binding to a null arrow::Tensor in TensorToSparseCOOTensor() at pyarrow/src/arrow/python/numpy_convert.cc:545
substrait.serialize_schema()
invalid arrow::Schema reference in _serialize_namedstruct_schema() at build/_substrait.cpp:11784
IndexOptions(...).serialize()
member access through a null arrow::Scalar at cpp/src/arrow/scalar.cc:715
ASan subsequently reports invalid reads on the corresponding native paths and aborts each process with exit code 134.
This appears related to #51041, which reports the same kind of failure in FunctionOptions.deserialize().
If separate issues are preferred for each API, I would be happy to report them individually.
serialize_expressions() appears to cast schema to Schema without validating its type,
while Declaration.from_sequence() appears to cast each sequence element to Declaration without validation.
A similar type validation approach used in PR #51163 may be needed for each element here as well.
Activity
marinelay commentedon Sep 8, 2026
I found another case of the same issue:
Both terminate with SIGSEGV on PyArrow 25.0.0.
serialize_expressions()appears to cast schema toSchemawithout validating its type,while
Declaration.from_sequence()appears to cast each sequence element toDeclarationwithout validation.A similar type validation approach used in PR #51163 may be needed for each element here as well.
apacheGH-51042: [Python] Reject invalid declarations in sequences
apacheGH-51042: Validate explicit Acero declaration inputs
apacheGH-51042: [Python] Reject invalid Arrow wrapper types
apacheGH-51042: [Python] Reject invalid declarations in sequences
apacheGH-51042: Validate explicit Acero declaration inputs
apacheGH-51042: [Python] Reject invalid Arrow wrapper types
apacheGH-51042: [Python] Reject invalid declarations in sequences
apacheGH-51042: Validate explicit Acero declaration inputs