Repository navigation
Memory exhaustion via crafted zip file #156002
Description
As reported by @tonghuaroot:
zipfile.ZipExtFile._read1() bounds the output of each decompress() call for DEFLATE members (it passes a max_length to zlib), but for bzip2 / LZMA / Zstandard members it called self._decompressor.decompress(data) with no bound. A whole compressed chunk was therefore expanded into a single allocation before the data = data[:self._left] clip ran.
Linked PRs
- gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard #156003
- [3.15] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (GH-156003) #156362
- [3.14] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (GH-156003) (GH-156362) #156737
- [3.13] gh-156002: Bound zipfile decompression for bzip2/LZMA (GH-156003) (GH-156362) #156738
- [3.12] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (GH-156003) (GH-156362) #156739
- [3.11] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (GH-156003) (GH-156362) #156740
- [3.10] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (GH-156003) (GH-156362) #156741
- gh-156002: Keep reading through third-party zipfile decompressors #157180
- [3.15] gh-156002: Keep reading through monkey-patched zipfile decompressors (GH-157180) #157268
- [3.14] gh-156002: Keep reading through monkey-patched zipfile decompressors (GH-157180) (GH-157268) #157557
Activity
encukou commentedon Sep 8, 2026
Please do. Thank you for the offer!
(Ideally add a
defaultarg to_decompressor_needs_input; using None/True/False for 3 states tends to get messy.)Not sure what you mean by “standard”. This kind of breakage is exactly what you should expect when monkey-patching private functions. Which doesn't mean we can't fix things when alerted, of course.
A better fix would be adding some registration API -- see #113767.
rasmusfaber commentedon Sep 8, 2026
Here you go: #157180
Ah, perhaps I should have said "the approach that third-part decompressor implementations have converged on". I totally agree that no promises were made not to break this approach.
Yes. When the eco-system starts to use hacks to extend, and those hacks starts to break, that is usually a smell that there need to be a standard plugin API.
gh-156002: Keep reading through monkey-patched zipfile decompressors (G…
pythongh-156002: Keep reading through monkey-patched zipfile decompre…
pythongh-156002: Keep reading through monkey-patched zipfile decompre…
[3.15] gh-156002: Keep reading through monkey-patched zipfile decompr…
[3.14] gh-156002: Keep reading through monkey-patched zipfile decompr…
pythongh-156002: Keep reading through monkey-patched zipfile decompre…
pythongh-156002: Keep reading through monkey-patched zipfile decompre…
pythongh-156002: Keep reading through monkey-patched zipfile decompre…
pythongh-156002: Keep reading through monkey-patched zipfile decompre…
Update python314 to version 3.14.7 / rev 40 via SR 1379535
Update python311 to version 3.11.16 / rev 74 via SR 1379773
[3.13] gh-156002: Bound zipfile decompression for bzip2/LZMA (GH-156003…
[3.12] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (
[3.10] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (
[3.11] gh-156002: Bound zipfile decompression for bzip2/LZMA/Zstandard (
Update python313 to version 3.13.15 / rev 46 via SR 1381538
Update python310 to version 3.10.21 / rev 83 via SR 1381747
Update python312 to version 3.12.14 / rev 54 via SR 1381748
Unzip: only allow `Stored` and `DEFLATE`