GHSA-fw94-4wwp-w8pw Excelize: A Zip64 uncompressed-size of 2^63 panics OpenFile/OpenReader

• Go github.com/xuri/excelize/v2: >= 2.1.0, < 2.11.1-0.20260805032953-db93f8d89de7 → fixed in 2.11.1-0.20260805032953-db93f8d89de7

Summary A Zip64 uncompressed-size of 2^63 casts to a negative int64 that bypasses the unzip-size guard and reaches make([]byte, 0, negativeCap) A Zip64 uncompressed-size in the range [2^63, 2^64) casts to a negative `int64` in `zip.File.FileInfo().Size()`, and `ReadZipReader` does signed arithmetic on that value, so the total-decompression guard is bypassed and the negative size reaches `make([]byte, 0, size)` in `readFile`. A 159-byte crafted file panics `OpenFile` and `OpenReader` with `runtime error: makeslice: cap out of range`. The guard, at `lib.go:44-46` on HEAD `ae2113b`: ```go fileSize := v.FileInfo().Size() unzipSize += fileSize if unzipSize > f.options.UnzipSizeLimit { return fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit) } ``` `FileInfo().Size()` returns `int64(UncompressedSize64)`. `UncompressedSize64` is read from the Zip64 extended-information extra record in the central directory and is fully attacker controlled, so any value with the top bit set arrives as a negative `int64`. `unzipSize` then goes negative and the comparison against `UnzipSizeLimit` (default `1000 f.options.UnzipXMLSizeLimit`), so the entry is not diverted to a temp file and control reaches `readFile`: ```go // lib.go:150 dat := make([]byte, 0, file.FileInfo().Size()) ``` `make` with a negative capacity panics. There is no `recover()` in any non-test file in the library, so the panic leaves the public API and takes down the calling goroutine. The asymmetry inside this same function is the clearest way to see it: `unzipToTemp` (`lib.go:83`) handles an entry with a plain `io.Copy` and never pre-allocates from the declared size, so it is indifferent to whatever the header claims. Only the pre-allocating branch trusts that number, and it trusts it after a signed comparison that a wrapped value walks straight through. Reproduction, executed against HEAD `ae2113b` (go1.26.5) A 159-byte archive was built with one stored entry named `xl/worksheets/sheet1.xml`: truthful 1-byte local header, central-directory 32-bit uncompressed size set to the `0xFFFFFFFF` Zip64 sentinel, and a Zip64 extra record (tag `0x0001`, data size 8) declaring `UncompressedSize64 = 0x8000000000000000`. ``` entry "xl/worksheets/sheet1.xml" FileInfo().Size() = -9223372036854775808 excelize.OpenReader(bytes.NewReader(raw)) -> panic: runtime error: makeslice: cap out of range ``` Control, the identical archive with `UncompressedSize64 = 0x7FFFFFFFFFFFFFFF`: ``` entry "xl/worksheets/sheet1.xml" FileInfo().Size() = 9223372036854775807 excelize.OpenReader(bytes.NewReader(raw)) -> err = "unzip size exceeds the 16777216000 bytes limit" ``` The control isolates the defect to the sign flip rather than to size magnitude: the guard behaves correctly for any positive declared size and fails only once the value wraps. `archive/zip` itself accepts the archive without complaint, so nothing upstream of excelize rejects it. What I verified and what I did not I ran both cases above myself and confirmed each cited line at HEAD. I caught the panic with a deliberate `recover` in my harness so I could print it; nothing in excelize recovers it, which I checked by grepping every non-test `.go` file. I did not separately run the `OpenFile` variant, since `OpenFile` reaches the same `ReadZipReader` loop, and I did not attempt to turn the bypassed size cap into a separate decompression-bomb primitive. Attacker model Any service that opens a spreadsheet it did not produce. The payload is 159 bytes, needs no authentication, and is deterministic. Suggested fix Compare against the limit in unsigned space, and bound the allocation independently rather than trusting the header: ```go if v.UncompressedSize64 > uint64(f.options.UnzipSizeLimit) { return fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit) } ``` and in `readFile`, reject or clamp a declared size that is negative or larger than the limit before calling `make`. The same unsigned treatment applies to the two `UnzipXMLSizeLimit` comparisons, which currently route a wrapped size away from the safe streaming path and into the pre-allocating one.