zipRemoveExtraInfoBlock() in contrib/minizip/zip.c reads a 2-byte
block-size field directly from the input buffer and uses it unchecked
as both a memcpy length and a pointer-advance amount, with no
validation against the buffer's actual remaining size (*dataLen).
Confirmed present, unmodified, in current master.
Reproducer (compiles against contrib/minizip/zip.c + zip.h):
#include "contrib/minizip/zip.h"
int main(void) {
char extra[4] = {0x11, 0x11, (char)0xff, 0x7f};
int len = sizeof(extra);
(void)zipRemoveExtraInfoBlock(extra, &len, (short)0x2222);
return 0;
}Build/run:
cc -O1 -g -fsanitize=address,undefined -fno-omit-frame-pointer \
harness.c contrib/minizip/zip.c -o repro
./repro
Result: AddressSanitizer heap-buffer-overflow, WRITE of size 32771
into a 4-byte allocation, aborts (SIGABRT).
==ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 32771 at ...
#1 zipRemoveExtraInfoBlock zip.c:1980
... 4-byte region ... allocated by ... zip.c:1965
This is a different function from CVE-2023-45853
(zipOpenNewFileInZip4_64). I could not find any real-world caller of
zipRemoveExtraInfoBlock in a broad GitHub code search across projects
that vendor this file, so real-world reachability is unconfirmed —
filing for the record since the function is public API (declared in
zip.h) and the fix is a simple bounds check before the memcpy/pointer
advance.
zipRemoveExtraInfoBlock()in contrib/minizip/zip.c reads a 2-byteblock-size field directly from the input buffer and uses it unchecked
as both a memcpy length and a pointer-advance amount, with no
validation against the buffer's actual remaining size (*dataLen).
Confirmed present, unmodified, in current master.
Reproducer (compiles against contrib/minizip/zip.c + zip.h):
Build/run:
Result: AddressSanitizer heap-buffer-overflow, WRITE of size 32771
into a 4-byte allocation, aborts (SIGABRT).
This is a different function from CVE-2023-45853
(zipOpenNewFileInZip4_64). I could not find any real-world caller of
zipRemoveExtraInfoBlock in a broad GitHub code search across projects
that vendor this file, so real-world reachability is unconfirmed —
filing for the record since the function is public API (declared in
zip.h) and the fix is a simple bounds check before the memcpy/pointer
advance.