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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions