Bug#1142906: unzip: heap buffer overflow WRITE in memextract() STORED path [CAN-2026-2034442]

Can you upload the zip file you used to generate the issue please?
________________________________
From: Akhil Koul <[email protected]>
Sent: 27 July 2026 19:09
To: [email protected] <[email protected]>
Subject: Bug#1142906: unzip: heap buffer overflow WRITE in memextract() STORED path [CAN-2026-2034442]

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

Hi,

InfoZIP unzip 6.0 contains a heap buffer overflow WRITE in the
memextract() function (extract.c) when processing STORED-compressed
VMS extra field blocks. The allocation uses the declared uncompressed
size (usiz), but the STORED copy path uses the compressed data length
(G.incnt, derived from csiz). When csiz > usiz, memcpy writes past
the heap buffer.

CAN: CAN-2026-2034442 (pending assignment from MITRE)
CWE: CWE-122 (Heap-based Buffer Overflow)
CVSS: 8.5 High

ROOT CAUSE:

In extract_izvms_block() (extract.c, line 2645):

    usiz = (cmptype == EB_IZVMS_BCSTOR ?
            csiz : makeword(ebdata+EB_IZVMS_UCSIZ));
    ...
    ucdata = (uch *)malloc(MAX(needlen, usiz));  // alloc'd with usiz

For the EB_IZVMS_BCDEFL case, memextract() is called:

    memextract(__G__ ucdata, (ulg)usiz,
               ebdata+EB_IZVMS_HLEN, (ulg)csiz);

Inside memextract() (extract.c, line 2523), the STORED path:

    G.inptr = (uch *)src + (2 + 4);
    G.incnt = (int)(G.csize = (long)(srcsize - (2 + 4)));  // from csiz
    ...
    case STORED:
        memcpy((char *)tgt, (char *)G.inptr, (extent)G.incnt);

The memcpy uses G.incnt (derived from srcsize/csiz) as the copy length,
but tgt is only usiz bytes. The method field inside the extra field data
is attacker-controlled — a crafted EF_IZVMS block declares
cmptype=EB_IZVMS_BCDEFL (to reach memextract) with a method byte of
STORED=0 inside the block data, usiz=16, and csiz=86. The memcpy then
copies 80 bytes into a 16-byte buffer.

TRIGGER: unzip -a -o poc.zip where poc.zip has version_made_by=0x0214
(VMS host system) and contains a crafted EF_IZVMS extra field with
the above geometry.

ASAN OUTPUT:

  ==8==ERROR: AddressSanitizer: heap-buffer-overflow on address
  0xffff98400740 at pc 0xaaaacd723054
  WRITE of size 80 at 0xffff98400740 thread T0
      #0 __asan_memcpy
      #1 memextract /build/unzip-6.0/extract.c:2523:13
      #2 extract_izvms_block /build/unzip-6.0/extract.c:2660:13
      #3 is_vms_varlen_txt /build/unzip-6.0/fileio.c:1181:32
      #4 flush /build/unzip-6.0/fileio.c:896:17
      #5 extract_or_test_member /build/unzip-6.0/extract.c:1921:21

  0xffff98400740 is located 0 bytes to the right of 16-byte region
  [0xffff98400730,0xffff98400740)
  allocated by thread T0 here:
      #1 extract_izvms_block /build/unzip-6.0/extract.c:2645:26

IMPACT: Heap buffer overflow WRITE with attacker-controlled length
(csiz - usiz - 6 bytes written past the allocation). This is a
write primitive — potential for code execution depending on heap
layout. Triggered during normal extraction of a crafted ZIP file.

SUGGESTED FIX (in memextract, STORED case):

    case STORED:
+       if ((extent)G.incnt > tgtsize) {
+           error = PK_ERR;
+           break;
+       }
        memcpy((char *)tgt, (char *)G.inptr, (extent)G.incnt);

Or equivalently, validate in extract_izvms_block() that csiz <= usiz + 6
before calling memextract with cmptype BCDEFL.

Best regards,
Akhil Koul