New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: PyArray_BufferConverter is unsafe #15450
Comments
This is strange. I think I would like if the buffer interface specified that while the buffer struct fields (such as strides, etc.) get free'd by Now this function returns a |
Your interpretation sounds more reasonable - perhaps a pull request against python/cpython would be wise, to update the docs to tell people not to implement what I described above. |
Was going to open, but then went to lunch first: https://bugs.python.org/issue39471 I may look into proposing actually changes to the text. If we can agree on my interpretation, we can clean up very ugly and very slow code in the buffer protocol implementation (it currently slows down scalar math by 20+%). (EDIT: But I suppose only after Python fixes their ArgParse code :() |
That adds some clarity, thanks - I hadn't realized that python was using the same reading as |
Damn, I had overread that before (from the PEP):
Which reads like it is valid to give the buffer a new chunk of memory :(. Although: looking at the implementation of |
This function:
PyObject_GetBuffer
PyBuffer_Release
PyBuffer_Release
callsPyBufferProcs.bf_releasebuffer(PyObject *exporter, Py_buffer *view)
, which according to the docs may "free all memory associated withview
", and gives no requirement thatview
remains alive as long asexporter
.So in principle a type that allocates a buffer for itself on the fly in
bf_getbuffer
and deletes it when the last uses releases it will cause a use-after-free in numpy.I don't know if any implementers of the buffer protocol actually do this, but my reading of it is that they are permitted to.
The text was updated successfully, but these errors were encountered: