Bug#1142905: unzip: stack out-of-bounds NUL write in EF_SMARTZIP handler [CAN-2026-2034443]

Package: unzip
Version: 6.0-28
Severity: grave
Tags: security
X-Debbugs-Cc: [email protected], [email protected]

Hi,

InfoZIP unzip 6.0 contains a stack out-of-bounds NUL byte write in the
EF_SMARTZIP (ID 0x4d63) extra field handler in zipinfo.c. An attacker-
controlled byte from the extra field data is used as an array index to
NUL-terminate a 32-byte stack buffer, without any bounds check.

CAN: CAN-2026-2034443 (pending assignment from MITRE)
CWE: CWE-787 (Out-of-bounds Write) / CWE-121 (Stack-based Buffer Overflow)
CVSS: High (stack OOB write)

ROOT CAUSE (zipinfo.c, lines 1766-1769):

    case EF_SMARTZIP:
        if ((eb_datalen == EB_SMARTZIP_HLEN) &&
            makelong(ef_ptr) == 0x70695A64 /* "dZip" */) {
            char filenameBuf[32];                     // 32-byte stack buffer
            zi_showMacTypeCreator(__G__ &ef_ptr[4]);
            memcpy(filenameBuf, &ef_ptr[33], 31);    // copies 31 bytes (safe)
            filenameBuf[ef_ptr[32]] = '\0';          // NUL WRITE at attacker-
                                                     // controlled index!
            ...

ef_ptr[32] is a byte from the extra field data (attacker-controlled,
range 0-255). filenameBuf is only 32 bytes (indices 0-31 valid). When
ef_ptr[32] > 31, the NUL write lands past the stack buffer boundary.
With ef_ptr[32] = 200, the write is at offset 200 — 168 bytes past
the end of the 32-byte buffer.

TRIGGER: zipinfo poc.zip (or unzip -Z -v poc.zip) where poc.zip has
a file with an EF_SMARTZIP extra field (ID 0x4d63) of exactly
EB_SMARTZIP_HLEN bytes, magic "dZip" at offset 0, and byte value > 31
at offset 32.

ASAN OUTPUT:

  ==8==ERROR: AddressSanitizer: stack-buffer-overflow on address
  0xffffeb74aeb8 at pc 0xaaaad8522268
  WRITE of size 1 at 0xffffeb74aeb8 thread T0
      #0 0xaaaad8522264 (zipinfo.c, EF_SMARTZIP handler)

  Address 0xffffeb74aeb8 is located in stack of thread T0:
    [336, 368) 'filenameBuf.i' (line 1704)
  Memory access at offset 536 overflows this variable (32 bytes at
  stack offset 336-368, write landed at offset 536 = 168 bytes past
  the end).

IMPACT: Stack buffer overflow (single NUL byte) with attacker-
controlled offset. While limited to writing a NUL byte, the offset
into the stack is fully controlled (0-255), allowing corruption of
saved frame pointers, local variables, or return addresses depending
on stack layout. At minimum: crash (DoS). Triggered by a user running
zipinfo on a crafted ZIP file.

SUGGESTED FIX:

    memcpy(filenameBuf, &ef_ptr[33], 31);
-   filenameBuf[ef_ptr[32]] = '\0';
+   {
+       unsigned idx = (unsigned)ef_ptr[32];
+       if (idx > 31) idx = 31;
+       filenameBuf[idx] = '\0';
+   }

Or more conservatively, always NUL-terminate at index 31:

    memcpy(filenameBuf, &ef_ptr[33], 31);
    filenameBuf[31] = '\0';

Best regards,
Akhil Koul