Repository navigation
Conversation
A 24 byte Zip64 extra field is accepted if it contains uncompressed size, compressed size and offset and they match the directory entry, even if not all of them are 0xFFFFFFFF there (nih-at#171). That layout has no room for the disk number. If disk number start was 0xFFFF, the disk number was taken either from past the end of the field (0, because _zip_buffer_set_offset() cleared the error of the failed read) or from the bytes of one of the other values. Assisted-by: Claude Code (Opus 5.5)
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #594.
The fallback for 24-byte Zip64 extra fields from 913b137 (#171) also accepted entries whose disk number start is 0xFFFF, although that layout has no room for a disk number. The disk number start then became 0 (the failed read was hidden by
_zip_buffer_set_offset()) or a copy of one of the other values.The fix remembers whether the disk number was read from the field and rejects that case with
ZIP_ER_DETAIL_INVALID_ZIP64_EF, as for 16- and 20-byte fields. 28-byte fields and the #171 case (disk number start 0) are unchanged.Such archives now fail to open with "invalid Zip64 extra field", with or without
ZIP_CHECKCONS, instead of opening with a made-up disk number start.New test
open_incons_zip64_ef_diskopens four archives with a 24-byte field and disk number start 0xFFFF (the two from the issue and two other layouts); all are rejected.open_zip64_ef_unneeded_offsetchecks that the #171 layout (both sizes 0xFFFFFFFF, offset not, disk number start 0) still opens withZIP_CHECKCONS.Under LeakSanitizer
open_incons_zip64_ef_diskonly passes with #592 applied, because of the leak intryopenfixed there.Assisted-by: Claude Code (Opus 5.5)