GH-51041: [Python] Reject non-Buffer FunctionOptions.deserialize input - #51129
Open
1fanwang wants to merge 1 commit into
Open
GH-51041: [Python] Reject non-Buffer FunctionOptions.deserialize input#511291fanwang wants to merge 1 commit into
1fanwang wants to merge 1 commit into
Conversation
|
|
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The change directly prevents a verified crash path by enforcing the documented input type and includes focused regression test coverage for the reported segfault cases.
Pull request overview
This PR hardens the PyArrow compute Python bindings by preventing pyarrow.compute.FunctionOptions.deserialize() from dereferencing a null C++ buffer when callers pass non-Buffer objects, converting a potential interpreter crash into a Python TypeError.
Changes:
- Tighten the
FunctionOptions.deserializeCython signature to requireBuffer buf not None, so invalid types are rejected before unwrapping. - Add a pytest parametrized regression test covering several non-
Bufferinputs that previously segfaulted.
File summaries
| File | Description |
|---|---|
| python/pyarrow/_compute.pyx | Adds a typed/non-null Buffer parameter to FunctionOptions.deserialize to prevent null dereference on invalid inputs. |
| python/pyarrow/tests/test_compute.py | Adds a regression test asserting TypeError for non-Buffer inputs to FunctionOptions.deserialize. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…e input deserialize() passed its argument straight to pyarrow_unwrap_buffer(), which returns a null pointer for anything that is not a Buffer. The following deref() then dereferenced null, so None, an int, a list or a bytes object crashed the interpreter instead of raising. Generated-by: GitHub Copilot CLI (Claude Opus 5) Signed-off-by: 1fanwang <1fannnw@gmail.com>
1fanwang
force-pushed
the
1fannnw/reject-non-buffer-deserialize
branch
from
September 1, 2026 23:36
4ee51c3 to
b725d23
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale for this change
Calling
pyarrow.compute.FunctionOptions.deserialize()with anything that is not aBuffercrashes the interpreter.None, anint, alistand abytesobject all segfault, so a caller who passes the wrong object, or who forwards an unvalidated value, loses the process rather than seeing an exception.deserialize()hands its argument topyarrow_unwrap_buffer(), which returns a null pointer for a non-Buffer. Thederef()on the next line then dereferences null.Before this change the call terminates the process. After it, the call raises
TypeErrornaming the type it received.What changes are included in this PR?
The static method now declares its parameter as
Buffer buf not None, which is what its docstring already says it takes. Cython rejects a wrong type before the unwrap runs, so the null pointer is never produced.Are these changes tested?
Yes, by a parametrized case over the four inputs above.
Red, with this commit's source file reverted to its parent
The same crash occurs for
1,[]andb''.Green, with the fix applied
A valid buffer still round-trips, and the rest of
test_compute.pyis unaffected.Round-trip and full suite
Are there any user-facing changes?
Passing a non-
BuffertoFunctionOptions.deserialize()now raisesTypeErrorinstead of terminating the process. Callers already passing aBuffer, which is what the docstring documents, are unaffected.FunctionOptions.deserialize()segfaults on non-buffer arguments #51041