The false positive is caused by the data descriptors that may optionally be present after compressed file entries. The descriptors contain three fields: a 32-bit CRC, and the compressed and uncompressed file sizes. The latter two fields can be either 32-bit or 64-bit. Currently, `unzip` assumes that if a file as a 64-bit offset in the archive, then its data descriptors are also 64-bit, but this is not always the case, as in the above case, where the total file size is larger than 4 GB but individual files are smaller and use 32-bit descriptors. This is a bit of a grey area of ZIP files. The PKWARE specification [1] doesn't explain clearly how the size of the data descriptor should be determined. In practice, mixing 32-bit and 64-bit data seems common, which is already accepted by some of the included patches such as unzip-zipbomb-part6.patch. Fortunately, the bug was detected already by Mark Adler in 2022 and fixed [2]. It's the last in a series of patches that is already being applied. Unfortunately, it conflicts with unzip-zipbomb-switch.patch ,but that patch can be rebased without too much effort. Proposed solution: Replace the unzip-zipbomb-switch.patch with the attached three patches: 1. unzip-zipbomb-part7.patch 2. unzip-zipbomb-part8.patch 3. unzip-zipbomb-switch-v2.patch References 1. https://pkwaredownloads.blob.core.windows.net/pem/APPNOTE.txt 2. https://github.com/madler/unzip/commit/af0d07f95809653b669d88aa0f424c6d5aa48ba0 3. https://src.fedoraproject.org/rpms/unzip/blob/rawhide/f/unzip-zipbomb-switch.patch Reproducible: Always Steps to Reproduce: This happens for many ZIP files that are larger than 4 GB. These are not very practical to attach, but I have been able to reproduce the problem with a Java program, which I've attached instead. This generates a 5 GB file that consists of 50 100 MB files. To reproduce: % javac ZipTest.java % java ZipTest % unzip -t java-generated.zip Archive: java-generated.zip testing: file-0.bin OK testing: file-1.bin OK .. testing: file-41.bin OK error: invalid zip file with overlapped components (possible zip bomb) To unzip the file anyway, rerun the command with UNZIP_DISABLE_ZIPBOMB_DETECTION=TRUE environmnent variable Or slightly faster: % unzip -t java-generated.zip file-48.bin file-49.bin Archive: java-generated.zip testing: file-48.bin OK error: invalid zip file with overlapped components (possible zip bomb) To unzip the file anyway, rerun the command with UNZIP_DISABLE_ZIPBOMB_DETECTION=TRUE environmnent variable Actual Results: unzip fails with an error. Expected Results: unzip should not fail with an error.
Created attachment 2085085 [details] Java program to generate test case
Created attachment 2085086 [details] Java program to generate test case (unused code removed)
Created attachment 2085087 [details] Fix false overlapped components detection on 32-bit systems.
Created attachment 2085088 [details] Be more liberal in the acceptance of data descriptors.
Created attachment 2085089 [details] Rebased unzip-zipbomb-switch.patch
Created attachment 2085765 [details] Python program to create a zip file that triggers this bug
Created attachment 2085766 [details] Example zip file that triggers the bug This is the output from ziptest.py; it can be used directly to reproduce the bug with e.g. `unzip -t python-generated.zip`. Note that python-generated.zip.xz is small (1 MB) but the uncompressed zipfile is large (5 GB).
*** This bug has been marked as a duplicate of bug 2360938 ***