When reading from the fileobj passed in it's constructor, zipfile.ZipExtFile passes a long into fileobj.read(). This is not normally an issue, except in io.BytesIO, for which the source is in C, and throws TypeError for type(bufsize) != int.

From what I can ascertain from the source, io.BytesIO.read() only expects an int because this type is merged with long in Python3*. I also believe io.BytesIO may have been backported and so this difference in the treatment of int and long was not picked up.

I have attached a test demonstrating the type failure, with comments for it's testing under Python3, where this evidently doesn't occur. It also compares results with io.BytesIO's predecessors, StringIO and cStringIO.

I would attach a patch but I'm unsure of the general process, so here instead are relevant lines of interest from the 2.6.4 vanilla source:
zipfile.py:447 ZipExtFile.bytes_read is assigned a long
zipfile.py:594 a long is passed to a fileobj (such as io.BytesIO)
_bytesio.c:222 the type of the argument to io.BytesIO.read() is checked to be an int

This was fixed with issue7249 and will be available with 2.6.5