Skip to content

Is mz_zip_entry_read_close suitable with non-NULL args? #840

@thbeu

Description

@thbeu

We have the following workflow to read an entry from file

// Pseudocode
int32_t err;
err = mz_zip_goto_entry(zip_handle, offset);
err = mz_zip_entry_get_info(zip_handle, ...);
auto read_bytes = mz_zip_entry_read(zip_handle, ...);
uint32_t expectedCRC32;
int64_t expectedCompressedSize;
int64_t expectedUncompressedSize;
err = mz_zip_entry_read_close(zip_handle, &expectedCRC32, &expectedCompressedSize, &expectedUncompressedSize);

We noticed that mz_zip_entry_read_close manipulates the stream if non-NULL args are passed

minizip-ng/mz_zip.c

Lines 2104 to 2110 in 55db144

/* Seek to end of compressed stream since we might have over-read during compression */
if (err == MZ_OK) {
err = mz_stream_seek(zip->stream,
MZ_ZIP_SIZE_LD_ITEM + (int64_t)zip->local_file_info.filename_size +
(int64_t)zip->local_file_info.extrafield_size + total_in,
MZ_SEEK_CUR);
}

However, the comment only speaks of compression which is not the case for a read-only archive.

Hence, we observed that the stream manipulation in mz_zip_entry_read_close lead to corrupt streams for reads of subsequent enries (mz_zip_entry_read_header fails on the MZ_ZIP_MAGIC_CENTRALHEADER check).

minizip-ng/mz_zip.c

Lines 233 to 234 in 55db144

else if ((!local) && (magic != MZ_ZIP_MAGIC_CENTRALHEADER))
err = MZ_FORMAT_ERROR;

As a workaround we simply call mz_zip_entry_close instead which solves the issue as now mz_zip_entry_read_close is called with NULL args.

Is it a file issue, an application issue or library issue? Thank you!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions