[ python-Bugs-1083110 ] truncated gzip file triggers zlibmodule
segfault
SourceForge.net
noreply at sourceforge.net
Tue Dec 28 21:32:52 CET 2004
Bugs item #1083110, was opened at 2004-12-10 13:54
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Sam Rushing (rushing)
Assigned to: A.M. Kuchling (akuchling)
Summary: truncated gzip file triggers zlibmodule segfault
Initial Comment:
If gzip.py reads a mangled/truncated file and leaves
the file pointer at EOF, the zlibmodule will crash when
it calls 'flush' (PyZlib_unflush()). I've traced through
zlib a bit, and I think the problem is that the 'avail_in'
slot of the decompression struct is left uninitialized.
The problem can be made to go away by setting that
slot to zero in either PyZlib_decompressobj(), or in
PyZlib_unflush() itself. However, I'm not familiar enough
with the code to know if there's some other reason
the slot contains garbage.
Reproduction:
>>> open ('x.gz', 'wb').write
('\x1f\x8b\x08\x08b\xee\xb9A\x00\x03x\x00')
>>> import gzip
>>> gzip.GzipFile ('x.gz', 'rb').read()
Segmentation fault (core dumped)
[the above data is simply a small gzip file truncated
after the zero-terminated filename]
----------------------------------------------------------------------
>Comment By: A.M. Kuchling (akuchling)
Date: 2004-12-28 15:32
Message:
Logged In: YES
user_id=11375
Applied to 2.4 and 2.3 maintenance branches. (2.2 is
probably affected, too, but I won't bother to backport the fix.)
Closing bug. Thanks for reporting the problem!
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2004-12-28 15:14
Message:
Logged In: YES
user_id=11375
Test case and fix committed:
Modules/zlibmodule.c: 2.67
Lib/test/test_zlib.py: 1.27
Misc/NEWS:1.1214
Backporting 2.4; will check 2.3.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2004-12-28 14:59
Message:
Logged In: YES
user_id=11375
If flush() is called without an intervening .decompress() call,
some fields in the zlib structure are left uninitialized.
I'll check in a test and fix.
The same problem exists with compression objects, but
calling flush()
doesn't result in a segfault. Perhaps the zlib code for
deflate() doesn't end up dereferencing the garbage fields;
I'll check in a fix anyway.
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2004-12-28 14:24
Message:
Logged In: YES
user_id=11375
Smaller test case:
import zlib
o = zlib.decompressobj()
d = o.flush()
It segfaults in PyZlib_unflush().
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-10 22:43
Message:
Logged In: YES
user_id=80475
On WinME, I can confirm segfaults in Py2.3 and Py2.4.
Andrew, I think this is your baby.
BTW, the OP's example would make an excellent testcase.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1083110&group_id=5470
More information about the Python-bugs-list
mailing list