This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: truncated gzip file triggers zlibmodule segfault
Type: Stage:
Components: Extension Modules Versions: Python 2.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: akuchling Nosy List: akuchling, rhettinger, rushing
Priority: high Keywords:

Created on 2004-12-10 18:54 by rushing, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg23635 - (view) Author: Sam Rushing (rushing) * Date: 2004-12-10 18:54
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]
msg23636 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-12-11 03:43
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.
msg23637 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2004-12-28 19:24
Logged In: YES 
user_id=11375

Smaller test case:

import zlib
o = zlib.decompressobj()
d = o.flush()

It segfaults in PyZlib_unflush().

msg23638 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2004-12-28 19:59
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.
msg23639 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2004-12-28 20:14
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.
msg23640 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2004-12-28 20:32
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!

History
Date User Action Args
2022-04-11 14:56:08adminsetgithub: 41306
2004-12-10 18:54:12rushingcreate