=== Summary ===

Stack buffer over-read in contrib/minizip/unzip.c. When
unzGetCurrentFileInfo()
is called with a buffer smaller than the ZIP entry filename, it fills the
buffer but does NOT null-terminate. Subsequent unzLocateFile() → strlen()
reads past the buffer boundary.

=== Root Cause ===

unzip.c:857-863
  if (file_info.size_filename < fileNameBufferSize) {
      *(szFileName + file_info.size_filename) = '\0';  // OK
  } else
      uSizeRead = fileNameBufferSize;  // BUG: no '\0'

unzip.c:1128
  if (strlen(szFileName) >= UNZ_MAXFILENAMEINZIP)  // CRASH

=== Reproduction (Ubuntu 24.04, libminizip1 1:1.3.dfsg-3.1ubuntu2.1) ===

$ gcc -fsanitize=address -g -I/usr/include/minizip \
      -o poc_minizip_overflow poc_minizip_stack_overflow.c \
      -lminizip -lz

$ ./poc_minizip_overflow poc_minizip_overflow.zip

[*] file_info.size_filename: 260
[*] filename_buf[255]: 0x42 (not 0x00 — buffer NOT null-terminated!)

==63292==ERROR: AddressSanitizer: stack-buffer-overflow
READ of size 257 at 0x7ffe67116ec0
    #0 strlen
    #1 unzLocateFile (/lib/x86_64-linux-gnu/libminizip.so.1+0x57f0)
    #2 main (poc_minizip_stack_overflow.c:82)

  [256, 512) 'filename_buf' ← Memory access at offset 512 overflows

=== Impact ===

- Stack info leak: strlen() reads adjacent stack data
- DoS: SIGSEGV if strlen() crosses unmapped page
- Any app using libminizip1 affected (file managers, archive tools,
  email scanners, web apps processing ZIP uploads)

=== Fix ===

  } else {
      uSizeRead = fileNameBufferSize > 0 ? fileNameBufferSize - 1 : 0;
      if (fileNameBufferSize > 0)
          *(szFileName + uSizeRead) = '\0';
  }

=== Attachments ===

PoC ZIP (260-byte filename) and C source code available.
Full ASAN output available on request.