[issue1372] zlibmodule.c: int overflow in PyZlib_decompress

[Peter Weseloh]

New submission from Peter Weseloh:

When I use zlib.decompress to decompress a string where the result would
be >1 GB I get
SystemError: Objects/stringobject.c:4089: bad argument to internal function

I tracked that down to an int overflow of r_strlen in PyZlib_decompress.
Using Py_ssize_t instead of int solved this for me (on 64bit Linux).

The patch is against
python/trunk/Modules/zlibmodule.c
Revision: 56476

Kind regards,
Peter

--
components: Extension Modules
files: int_overflow.diff
messages: 57047
nosy: PeterW
severity: normal
status: open
title: zlibmodule.c: int overflow in PyZlib_decompress
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file8676/int_overflow.diff

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1372>
__

int_overflow.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1372] zlibmodule.c: int overflow in PyZlib_decompress

[Peter Weseloh]

Peter Weseloh added the comment:

You are right. The format should be 'l'. I overlooked that. In my case the
optional 'buf_size' parameter of 'decompress' is not used anyhow.
Shall I change the patch accordingly?

It work well for me and I now checked the code of PyArg_ParseTuple
(Python/getargs.c) to see what happens. As far as I understand, the given
pointer is casted to a pointer to int if the format is 'i' (line  630) . On
a 64 bit machine this leads to a downcast from a (64 bit) long to a (32 bit)
int, which is OK AFAIK, but I could be wrong.

Thanks for pointing that out,
Peter
2007/11/2, Guido van Rossum <[EMAIL PROTECTED]>:
>
>
> Guido van Rossum added the comment:
>
> I trust that there's a problem, but this can't be right -- the address
> of r_strlen is passed to PyArg_ParseTuple corresponding to an 'i' format
> letter.  That will never do.
>
> --
> assignee:  -> nnorwitz
> nosy: +gvanrossum, nnorwitz
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1372>
> __
>

Added file: http://bugs.python.org/file8681/unnamed

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1372>
__You are right. The format should be 'l'. I overlooked that. In my case 
the optional 'buf_size' parameter of 'decompress' is not used 
anyhow.Shall I change the patch accordingly?It work well for me and 
I now checked the code of PyArg_ParseTuple (Python/getargs.c) to see what 
happens. As far as I understand, the given pointer is casted to a pointer to 
int if the format is 'i' (line  630) . On a 64 bit machine this 
leads to a downcast from a (64 bit) long to a (32 bit) int, which is OK AFAIK, 
but I could be wrong. 
Thanks for pointing that out,Peter2007/11/2, Guido van Rossum <mailto:[EMAIL 
PROTECTED]">[EMAIL PROTECTED]>:
Guido van Rossum added the comment:I trust that there's a 
problem, but this can't be right -- the addressof r_strlen is passed to 
PyArg_ParseTuple corresponding to an 'i' 
formatletter.  That will never do.
--assignee:  -> nnorwitznosy: +gvanrossum, 
nnorwitz__Tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]><http://bugs.python.org/issue1372";>
http://bugs.python.org/issue1372>__

___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com