BZ2_Malloc() checks for size < 0 at https://github.com/python/cpython/blob/6015cc50bc38b9e920ce4986ee10658eaa14f561/Modules/_bz2module.c#L278 , but doesn't check for size == 0 before dividing by it:

    if (items < 0 || size < 0)
        return NULL;
    if ((size_t)items > (size_t)PY_SSIZE_T_MAX / (size_t)size)
        return NULL;

Reported by Svace static analyzer.

Check other wrappers to memory allocators:

* zlib: "zst.zalloc = PyZlib_Malloc" which calls PyMem_RawMalloc
* _lzma: "self->alloc.alloc = PyLzma_Malloc" which calls PyMem_RawMalloc
* _bz2: "bzalloc = BZ2_Malloc" which calls PyMem_RawMalloc()

https://bugs.python.org/issue35056#msg328533

May be we should add a new function (_PyMem_RawMallocItems?) that does the same checks as PyMem_RawCalloc, but doesn't zero-initialize memory?

> May be we should add a new function (_PyMem_RawMallocItems?) that does the same checks as PyMem_RawCalloc, but doesn't zero-initialize memory?

Please don't add new functions to the Python memory allocators. We already have too many of them :-(
https://docs.python.org/dev/c-api/memory.html

PyZlib_Malloc, PyLzma_Malloc and BZ2_Malloc exists because they use different types: 2 unsigned int (zlib), 2 size_t (lzma), 2 int (bz2). PyMem_RawMalloc() expects a single size_t.

IMHO it's fine to have a function of 5 lines of code in each module, since each module uses a different C type.

New changeset 3d4fabb2a424cb04ae446ebe4428090c386f45a5 by Victor Stinner (Alexey Izbyshev) in branch 'master':
bpo-35090: Fix potential division by zero in allocator wrappers (GH-10174)
https://github.com/python/cpython/commit/3d4fabb2a424cb04ae446ebe4428090c386f45a5

I don't want to backport this change. IMHO these wrappers are never called with 0. Otherwise, I'm sure that someone would report the crash...

But I applied the change anyway, just to avoid future reports of static analyzers :-) And the cast doesn't hurt :-)

Thanks, Victor. Regarding backporting, what about integer overflow? Do you think it's guaranteed that the multiple of items and size always fits in 32-bit types, in case of BZ2_Malloc and PyZlib_Malloc?

Sorry for changing the status, it's browser caching again.

> Regarding backporting, what about integer overflow? Do you think it's guaranteed that the multiple of items and size always fits in 32-bit types, in case of BZ2_Malloc and PyZlib_Malloc?

I don't know. Serhiy: What do you think?

I think it is worth to backport. Perhaps it is possible even to create a reproducer for integer overflow, but I afraid it will be too slow for using in tests.

Serhiy: "I think it is worth to backport."

Ok. I asked the bot to create 3.6 and 3.7 backports, and I just approved them.

I checked: Python 2.7 is not affected.

New changeset 1d7d165e3c3f07518e6b5bfb57f1fd460cd4bbf2 by Miss Islington (bot) in branch '3.7':
bpo-35090: Fix potential division by zero in allocator wrappers (GH-10174)
https://github.com/python/cpython/commit/1d7d165e3c3f07518e6b5bfb57f1fd460cd4bbf2

New changeset fd0a3bce6e917b5853c809a309c1513acc176f56 by Miss Islington (bot) in branch '3.6':
bpo-35090: Fix potential division by zero in allocator wrappers (GH-10174)
https://github.com/python/cpython/commit/fd0a3bce6e917b5853c809a309c1513acc176f56

Ok, now we should be good :-) I close again the issue.

Note: Serhiy Stochaka considers that no NEWS entry is needed and I concur with him.