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
bpo-41175: Guard against a possible NULL pointer dereference within bytearrayobject #21240
Conversation
Objects/bytearrayobject.c
Outdated
| @@ -267,6 +267,7 @@ PyByteArray_Concat(PyObject *a, PyObject *b) | |||
| result = (PyByteArrayObject *) \ | |||
| PyByteArray_FromStringAndSize(NULL, va.len + vb.len); | |||
| if (result != NULL) { | |||
| assert(result->ob_bytes != NULL); | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like it can be NULL if PyByteArray_FromStringAndSize() is called with size=0: if va.len+vb.len=0 (if both strings are empty).
At least, I don't see any code path handling handling this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Python code bytearray() + bytearray() triggers exactly this case. It seems like with the glibc, memcpy(NULL, _PyByteArray_empty_string, 0) doesn't crash. But as I far as I recall, it's an undefined behavior.
We should avoid calling memcpy() with n=0.
See:
- https://bugs.python.org/issue22605
- https://bugs.python.org/issue27570
- https://bugs.python.org/issue31347
- https://stackoverflow.com/questions/29844298/is-it-legal-to-call-memcpy-with-zero-length-on-a-pointer-just-past-the-end-of-an
Try also UBSan of clang.
cc @benjaminp @tiran
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, this assert is not correct.
What about only doing the first memcpy if va.len is non-zero, and the second one iff vb.len is non-zero? ISTM that if memcpy is inlined, the compiler would have a chance to skip the check.
Misc/NEWS.d/next/Core and Builtins/2020-06-30-20-17-31.bpo-41175.acJoXB.rst
Outdated
Show resolved
Hide resolved
…bject The issue is triggered by the bytearray() + bytearray() operation. Detected by GCC 10 static analysis tool
|
I merged your PR, thanks. @stratakis: Is a backport needed? |
I would say yes, the issue affects previous releases as well. |
|
Thanks @stratakis for the PR, and @vstinner for merging it |
|
GH-21431 is a backport of this pull request to the 3.9 branch. |
…bject (pythonGH-21240) The issue is triggered by the bytearray() + bytearray() operation. Detected by GCC 10 static analysis tool. (cherry picked from commit 61fc23c) Co-authored-by: stratakis <cstratak@redhat.com>
|
Thanks @stratakis for the PR, and @vstinner for merging it |
|
GH-21432 is a backport of this pull request to the 3.8 branch. |
…bject (pythonGH-21240) The issue is triggered by the bytearray() + bytearray() operation. Detected by GCC 10 static analysis tool. (cherry picked from commit 61fc23c) Co-authored-by: stratakis <cstratak@redhat.com>
…bject (pythonGH-21240) The issue is triggered by the bytearray() + bytearray() operation. Detected by GCC 10 static analysis tool.
…bject (pythonGH-21240) The issue is triggered by the bytearray() + bytearray() operation. Detected by GCC 10 static analysis tool.
Detected by GCC 10 static analysis tool
https://bugs.python.org/issue41175