homepage

zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, and uses lots of "int" variables for length values internally.
Besides, the zlib itself uses "uInt" and "uLong" variables in its z_stream structure (rather than something guaranteed to be at least the width of a pointer).
On large input data, this will conspire to produce bogus results or crashes. For example:
>>> s = 'x' * (4 * 1024**3 + 100)
>>> t = zlib.compress(s, 1)
>>> len(t)
12
>>> len(zlib.decompress(t))
100

See also a related issue: #8651.

Fixed by r87729.
Wait for the buildbots before backporting to other versions.

Woops, I removed a duplicate message of Antoine. in this issue instead of #8651. Removed message:
-----
> Fixed by r87729.
This only addresses the compress() and decompress() functions, but e.g. crc32() and adler32() are also touched by this issue.
-----

> This only addresses the compress() and decompress() functions, 
> but e.g. crc32() and adler32() are also touched by this issue.
crc32() and adler32() were fixed by #10276.
PyZlib_objcompress() and PyZlib_objdecompress() should be fixed.

New changeset 850624632e9a by Nadeem Vawda in branch '3.1':
Issue #8650: Backport 64-bit safety fixes for compress() and decompress().
http://hg.python.org/cpython/rev/850624632e9a
New changeset 99a3ce22c1ff by Nadeem Vawda in branch '3.2':
Null merge (#8650): zlib.compress() and .decompress() are already 64-bit safe.
http://hg.python.org/cpython/rev/99a3ce22c1ff
New changeset dea5fcdc9ecd by Nadeem Vawda in branch 'default':
Null merge (#8650): zlib.compress() and .decompress() are already 64-bit safe.
http://hg.python.org/cpython/rev/dea5fcdc9ecd 

New changeset 0b5211d19a14 by Nadeem Vawda in branch '3.1':
Issue #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/0b5211d19a14
New changeset 3ff862d05d18 by Nadeem Vawda in branch '3.2':
Merge: #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/3ff862d05d18
New changeset f86a22b6ab58 by Nadeem Vawda in branch 'default':
Merge: #8650: Make zlib.[de]compressobj().[de]compress() 64-bit clean.
http://hg.python.org/cpython/rev/f86a22b6ab58 

Fixed in 3.1, 3.2 and 3.3.
2.7 no longer has this problem -- the fix for issue8651 ensures that the
functions cannot receive inputs large enough to be problematic (since we
don't define PY_SSIZE_T_CLEAN).