Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is mz_zip_entry_read_close suitable with non-NULL args? #840

Open
thbeu opened this issue Feb 18, 2025 · 3 comments
Open

Is mz_zip_entry_read_close suitable with non-NULL args? #840

thbeu opened this issue Feb 18, 2025 · 3 comments

Comments

@thbeu
Copy link

thbeu commented Feb 18, 2025

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!

@nmoinvaz
Copy link
Member

nmoinvaz commented Mar 5, 2025

That comment should say decompression not compression.

@nmoinvaz
Copy link
Member

nmoinvaz commented Mar 5, 2025

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).

I'm not sure what the particulars of your zip are. Is it using data descriptors? Can you attach it?

@thbeu
Copy link
Author

thbeu commented Mar 6, 2025

Thanks for replying. Please find the zip archive attached. It is the archive file Aufschluesse.zip within the attached file: Issue840.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants