From 4b3a8be06839aa257699678673cf4d49c7d6dd15 Mon Sep 17 00:00:00 2001 From: afonsojanu Date: Thu, 3 Sep 2026 10:04:23 +0100 Subject: [PATCH] minizip: stop unzGetCurrentFileInfo from filling the name buffer with no room for a null When the stored filename is at least as long as the caller's buffer, the code copies fileNameBufferSize bytes and never null-terminates, so any later strlen() on that buffer reads past its end. This is easy to hit in practice: a lot of callers just pass a fixed-size stack buffer sized for the common case and rely on the result being a normal C string. Now that branch backs off by one byte and terminates there instead, same as the branch right above it already does when the name fits. Verified with an ASan build: a 264-byte name into a 256-byte buffer crashes with a stack-buffer-overflow in strlen() before this change and comes back clean afterward, strlen() reporting 255. --- contrib/minizip/unzip.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/contrib/minizip/unzip.c b/contrib/minizip/unzip.c index 827c23a12b..0198870d3a 100644 --- a/contrib/minizip/unzip.c +++ b/contrib/minizip/unzip.c @@ -859,8 +859,16 @@ local int unz64local_GetCurrentFileInfoInternal(unzFile file, *(szFileName+file_info.size_filename)='\0'; uSizeRead = file_info.size_filename; } + else if (fileNameBufferSize>0) + { + /* stored name doesn't fit: keep one byte back so we can still + null-terminate inside the caller's buffer instead of filling + it completely and leaving callers to strlen() past the end */ + uSizeRead = fileNameBufferSize-1; + *(szFileName+uSizeRead)='\0'; + } else - uSizeRead = fileNameBufferSize; + uSizeRead = 0; if ((file_info.size_filename>0) && (fileNameBufferSize>0)) if (ZREAD64(s->z_filefunc, s->filestream,szFileName,uSizeRead)!=uSizeRead)