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.
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.
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.
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 🌮🎉.. I'm working now to backport this PR to: 3.9. |
|
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 <[email protected]>
|
Thanks @stratakis for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8. |
|
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 <[email protected]>
…bject (GH-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 <[email protected]>
…bject (GH-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 <[email protected]>
…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