CVE-2026-54616

This vulnerability isn't a simple forgotten check — it's an API contract mismatch that static tooling couldn't catch. NanaZip's LZ4 decompressor checks for zero to detect errors, but LZ4 signals failures with negative integers. When that negative error value propagates, it gets implicitly cast to an unsigned SizeT, wrapping to a massive positive value. The code compiles cleanly because modern compilers don't warn on signed-to-unsigned conversions in assignment contexts, even when the signed value is a known error sentinel. That corrupted size becomes _cachedUnpackBlockSize, which controls memcpy bounds during fragment extraction from SquashFS archives. If an attacker controls the inode Offset in a malformed SquashFS file, the decompressor will read arbitrary heap contents into output files. This is a data-leakage vector, not just a crash — and it's exploitable because NanaZip processes untrusted input by design, integrated into Windows shell handlers and Quick Look previews where the vulnerable code executes without user interaction. The root cause is copy-paste integration. The SquashFS handler was almost certainly ported from another 7-Zip derivative, likely adapted from a handler using a different compression library (LZMA uses zero for errors, Zstd uses negative frame errors). The developer carried forward the error-checking pattern without recognizing that LZ4 requires a `< 0` check instead of `!= 0`. This is a known failure mode in the 7-Zip fork ecosystem — institutional memory about why code was written a certain way gets severed at each branch. Check your NanaZip version: 6.0.1698.0 and 6.5.1742.0 contain the fix. But also audit any other compression handlers in NanaZip or its derivative forks — Zstd, Brotli, LZFSE — for the same `< 0` vs `!= 0` error convention mismatch. If handlers were cloned without reviewing the API contract, this pattern almost certainly exists elsewhere in the ecosystem.

Reviewed through automated stages and approved by a human before publication.