libminizip1 (1.1-8build1) does not write the correct number of files in the zip header if number of files > 0xFFFF and file size < 4gb

[Paul F Richards]

If more than 0xFFFF files are written using the minizip library and the file size is less than 4gb (32-bit limit) the 64-bit zip central directory record is not written and the correct number of files is not written in the header (truncated at 0xFFFF). The default latest 'unzip' package in Ubuntu 22.04 and 20.04 will extract all the files but print a confusing error if -q (quiet parameter) is passed to it:

"error: expected central file header signature not found (file #%lu).\n"
"(please check that you have transferred or created the zipfile in the\n"
" appropriate BINARY mode and that you have compiled UnZip properly)"

unzip will also return 3 indicating an error.

A simple fix is provided in this patch:

--- minizip-1.1/zip.c 2010-02-14 23:59:40.000000000 -0500
+++ minizip-1.1.1/zip.c 2022-07-27 15:25:47.146666009 -0400
@@ -1919,7 +1919,7 @@ extern int ZEXPORT zipClose (zipFile fil
     free_linkedlist(&(zi->central_dir));

     pos = centraldir_pos_inzip - zi->add_position_when_writting_offset;
- if(pos >= 0xffffffff)
+ if(pos >= 0xffffffff || zi->number_entry > 0xFFFF)
     {
       ZPOS64_T Zip64EOCDpos = ZTELL64(zi->z_filefunc,zi->filestream);
       Write_Zip64EndOfCentralDirectoryRecord(zi, size_centraldir, centraldir_pos_inzip);

[Paul F Richards (paulrichards321)]

Attached is the patch for zip.c.

[Paul F Richards (paulrichards321)]

Below is a (optional) patch that enables the minizip to read a list of files separated by newlines for zipping. If used with more than 0xFFFF files and the files are small it will trigger this error.

[Paul F Richards (paulrichards321)]

The problem can be highlighted on lines 1829-1834 in zip.c function Write_EndOfCentralDirectoryRecord:

     if(zi->number_entry >= 0xFFFF)
        err = zip64local_putValue(&zi->z_filefunc,zi->filestream,(uLong)0xffff,2); // use value in ZIP64 record
      else
        err = zip64local_putValue(&zi->z_filefunc,zi->filestream,(uLong)zi->number_entry,2);

The comment reads use value in ZIP64 record but if the ZIP64 record is not recorded than the record count will be wrong. There is no check currently to see if the number of files is above 0xFFFF to write the Zip64 End of Central Directory (only if the file pos is > 0xffffffff):

    pos = centraldir_pos_inzip - zi->add_position_when_writting_offset;
    if(pos >= 0xffffffff)
    {
      ZPOS64_T Zip64EOCDpos = ZTELL64(zi->z_filefunc,zi->filestream);
      Write_Zip64EndOfCentralDirectoryRecord(zi, size_centraldir, centraldir_pos_inzip);

      Write_Zip64EndOfCentralDirectoryLocator(zi, Zip64EOCDpos);
    }

[Paul F Richards (paulrichards321)]

On the Windows 10 Version I have, 10.0.19044.1826, the problem is worse. If you take the zip file there with this bug and open it with the native file explorer it will only show or extract the first 65,535 files.

See attachment for screenshots.

After using my patch it correctly shows and extracts all the files.

(See screenshots: DP035 is the folder I zipped)

[Paul F Richards (paulrichards321)]

See attached for Windows 10 native file explorer extracting zip file after zip.c patch!

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "zip.patch.txt" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]