Reject a Zip64 uncompressed size that does not fit a signed int64

[arpitjain099]

Follows up on the advisory discussion, where you asked whether I wanted to send a patch.

zip.File.FileInfo().Size() returns int64(UncompressedSize64), and UncompressedSize64 comes from the Zip64 extended information extra field in the central directory. Any declared value in [2^63, 2^64) turns negative on that conversion, and the guard in ReadZipReader is signed arithmetic, so:

• unzipSize += fileSize makes the running total negative, and unzipSize > f.options.UnzipSizeLimit stays false, so the decompression cap never fires
• the two UnzipXMLSizeLimit comparisons are false as well, so a large part is never routed to a temporary file
• readFile reaches make([]byte, 0, negative), which panics with makeslice: cap out of range

A 159 byte archive is enough to reach it through OpenFile, OpenReader or ReadZipReader, and nothing in the library recovers, so the panic propagates to the caller.

The change

Compare the declared size against the limit as a uint64 before it is narrowed. An entry that cannot fit is rejected on its own, so the signed arithmetic below only ever sees a value already within the limit, and fileSize can no longer be negative. The UnzipSizeLimit < 0 clause keeps the conversion honest if someone configures a negative limit.

readFile also bounds its capacity hint, so the allocation is safe regardless of how that function is reached. It takes the limit as a parameter since it is package level and has no access to f.options; there is one caller.

Testing

TestZip64UncompressedSizeOverflow builds the archive in memory rather than committing a fixture. It asserts the declared size really is negative after conversion, then that OpenReader returns the unzip size limit error instead of panicking. It also runs a control at 2^63-1, one below the sign flip, which already returned the limit error before this change. That is what pins the bug to the conversion rather than to the size being large.

Verified fail before and pass after: on master the new test panics with makeslice: cap out of range, and with the fix it passes. Full suite is green locally on go1.26.5 darwin/arm64.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.62%. Comparing base (ad2cb3e) to head (db7b243).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2369   +/-   ##
=======================================
  Coverage   99.62%   99.62%           
=======================================
  Files          32       32           
  Lines       26979    26994   +15     
=======================================
+ Hits        26877    26892   +15     
  Misses         53       53           
  Partials       49       49           

Flag	Coverage Δ
unittests	99.62% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[xuri]

Thanks for your contribution. I've made some changes based on your branch.

[arpitjain099]

Thakn you @xuri Yesterday and today have been busy, will look at your feedback items later in the evening.

[xuri]

Thakn you @xuri Yesterday and today have been busy, will look at your feedback items later in the evening.

No worries, I've made some changes based on your branch. Please take a look for my changes. If your have any additional suggestions, please let me know.