From f9390b6599162e48909fcdd170386df4ee8e0397 Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Sat, 27 Jan 2024 07:10:46 +0000 Subject: [PATCH 01/10] Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild --- unzip.spec | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/unzip.spec b/unzip.spec index b6f20ef..801a573 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 62%{?dist} +Release: 63%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -145,6 +145,9 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Sat Jan 27 2024 Fedora Release Engineering - 6.0-63 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild + * Sat Jul 22 2023 Fedora Release Engineering - 6.0-62 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild From e198018c317d8f1500fb4a101beffeeeeb3d9ccc Mon Sep 17 00:00:00 2001 From: Software Management Team Date: Thu, 30 May 2024 12:46:49 +0200 Subject: [PATCH 02/10] Eliminate use of obsolete %patchN syntax (#2283636) --- unzip.spec | 70 +++++++++++++++++++++++++++--------------------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/unzip.spec b/unzip.spec index 801a573..c445716 100644 --- a/unzip.spec +++ b/unzip.spec @@ -91,42 +91,42 @@ a zip archive. %prep %setup -q -n unzip60 -%patch1 -p1 -%patch2 -p1 -%patch3 -p1 -%patch4 -p1 -%patch5 -p1 -%patch6 -p1 -%patch7 -p1 -%patch8 -p1 -%patch9 -p1 -%patch10 -p1 -%patch11 -p1 -%patch12 -p1 -%patch13 -p1 -%patch14 -p1 -%patch15 -p1 -%patch16 -p1 -%patch17 -p1 -%patch18 -p1 -%patch19 -p1 -%patch20 -p1 -%patch21 -p1 -%patch22 -p1 -%patch23 -p1 -%patch24 -p1 -%patch25 -p1 +%patch -P1 -p1 +%patch -P2 -p1 +%patch -P3 -p1 +%patch -P4 -p1 +%patch -P5 -p1 +%patch -P6 -p1 +%patch -P7 -p1 +%patch -P8 -p1 +%patch -P9 -p1 +%patch -P10 -p1 +%patch -P11 -p1 +%patch -P12 -p1 +%patch -P13 -p1 +%patch -P14 -p1 +%patch -P15 -p1 +%patch -P16 -p1 +%patch -P17 -p1 +%patch -P18 -p1 +%patch -P19 -p1 +%patch -P20 -p1 +%patch -P21 -p1 +%patch -P22 -p1 +%patch -P23 -p1 +%patch -P24 -p1 +%patch -P25 -p1 -%patch26 -p1 -%patch27 -p1 -%patch28 -p1 -%patch29 -p1 -%patch30 -p1 -%patch31 -p1 -%patch32 -p1 -%patch33 -p1 -%patch34 -p1 -%patch35 -p1 +%patch -P26 -p1 +%patch -P27 -p1 +%patch -P28 -p1 +%patch -P29 -p1 +%patch -P30 -p1 +%patch -P31 -p1 +%patch -P32 -p1 +%patch -P33 -p1 +%patch -P34 -p1 +%patch -P35 -p1 %build # IZ_HAVE_UXUIDGID is needed for right functionality of unzip -X From 5db7630b976ac298fb5d193b13fb01a1aac5ad5e Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Sat, 20 Jul 2024 08:19:55 +0000 Subject: [PATCH 03/10] Rebuilt for https://fedoraproject.org/wiki/Fedora_41_Mass_Rebuild --- unzip.spec | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/unzip.spec b/unzip.spec index c445716..3725e7c 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 63%{?dist} +Release: 64%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -145,6 +145,9 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Sat Jul 20 2024 Fedora Release Engineering - 6.0-64 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_41_Mass_Rebuild + * Sat Jan 27 2024 Fedora Release Engineering - 6.0-63 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild From 8ce8569f5add999ea9e957341d772eeca165f117 Mon Sep 17 00:00:00 2001 From: Jakub Martisko Date: Mon, 25 Nov 2024 12:15:34 +0100 Subject: [PATCH 04/10] Zipinfo: remove the extra %c in the help message The extra %c caused invalid memory reads and thus a bogus output in the help message. Also fix the white4space fomrmating of the help message. Related: RHEL-59972 --- unzip-6.0-alt-iconv-utf8.patch | 12 ++++++------ unzip.spec | 7 ++++++- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/unzip-6.0-alt-iconv-utf8.patch b/unzip-6.0-alt-iconv-utf8.patch index b9e3777..1db3164 100644 --- a/unzip-6.0-alt-iconv-utf8.patch +++ b/unzip-6.0-alt-iconv-utf8.patch @@ -174,11 +174,11 @@ Index: unzip-6.0/unzip.c +#else /* UNIX */ +static ZCONST char Far ZipInfoUsageLine3[] = "miscellaneous options:\n\ + -h print header line -t print totals for listed files or for all\n\ -+ -z print zipfile comment %c-T%c print file times in sortable decimal format\ -+\n %c-C%c be case-insensitive %s\ ++ -z print zipfile comment -T print file times in sortable decimal format\ ++\n -C be case-insensitive %s\ + -x exclude filenames that follow from listing\n\ -+ -O CHARSET specify a character encoding for DOS, Windows and OS/2 archives\n\ -+ -I CHARSET specify a character encoding for UNIX and other archives\n"; ++ -O CHARSET specify a character encoding for DOS, Windows and OS/2 archives\n\ ++ -I CHARSET specify a character encoding for UNIX and other archives\n"; +#endif /* !UNIX */ #ifdef MORE static ZCONST char Far ZipInfoUsageLine4[] = @@ -196,8 +196,8 @@ Index: unzip-6.0/unzip.c + -U use escapes for all non-ASCII Unicode -UU ignore any Unicode fields\n\ + -C match filenames case-insensitively -L make (some) names \ +lowercase\n %-42s -V retain VMS version numbers\n%s\ -+ -O CHARSET specify a character encoding for DOS, Windows and OS/2 archives\n\ -+ -I CHARSET specify a character encoding for UNIX and other archives\n\n"; ++ -O CHARSET specify a character encoding for DOS, Windows and OS/2 archives\n\ ++ -I CHARSET specify a character encoding for UNIX and other archives\n\n"; #else /* !VMS */ static ZCONST char Far UnzipUsageLine4[] = "\ modifiers:\n\ diff --git a/unzip.spec b/unzip.spec index 3725e7c..af446d0 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 64%{?dist} +Release: 65%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -145,6 +145,11 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Mon Nov 25 2024 Jakub Martisko - 6.0-65 +- Zipinfo: remove the extra %c that cause invalid reads +- Zipinfo: fix the whitespace formating of the help message +Related: RHEL-59972 + * Sat Jul 20 2024 Fedora Release Engineering - 6.0-64 - Rebuilt for https://fedoraproject.org/wiki/Fedora_41_Mass_Rebuild From d68244a849ae9f4e7f130a3d25156207212c5c36 Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Sun, 19 Jan 2025 13:50:13 +0000 Subject: [PATCH 05/10] Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild --- unzip.spec | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/unzip.spec b/unzip.spec index af446d0..0003f18 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 65%{?dist} +Release: 66%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -145,6 +145,9 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Sun Jan 19 2025 Fedora Release Engineering - 6.0-66 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild + * Mon Nov 25 2024 Jakub Martisko - 6.0-65 - Zipinfo: remove the extra %c that cause invalid reads - Zipinfo: fix the whitespace formating of the help message From 392770fc88d942153bd5354717a9df63d7180a2c Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Fri, 25 Jul 2025 19:49:30 +0000 Subject: [PATCH 06/10] Rebuilt for https://fedoraproject.org/wiki/Fedora_43_Mass_Rebuild --- unzip.spec | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/unzip.spec b/unzip.spec index 0003f18..2678116 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 66%{?dist} +Release: 67%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -145,6 +145,9 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Fri Jul 25 2025 Fedora Release Engineering - 6.0-67 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_43_Mass_Rebuild + * Sun Jan 19 2025 Fedora Release Engineering - 6.0-66 - Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild From 97c9106ddc217ee17c1e9c7b73270cce1c424183 Mon Sep 17 00:00:00 2001 From: Jakub Martisko Date: Wed, 20 Aug 2025 11:23:24 +0200 Subject: [PATCH 07/10] Another zipbomb patch --- unzip-zipbomb-part7.patch | 172 +++++++++++++++++++++++++++++++++++++ unzip-zipbomb-switch.patch | 27 ++---- unzip.spec | 14 ++- 3 files changed, 189 insertions(+), 24 deletions(-) create mode 100644 unzip-zipbomb-part7.patch diff --git a/unzip-zipbomb-part7.patch b/unzip-zipbomb-part7.patch new file mode 100644 index 0000000..4edc152 --- /dev/null +++ b/unzip-zipbomb-part7.patch @@ -0,0 +1,172 @@ +From af0d07f95809653b669d88aa0f424c6d5aa48ba0 Mon Sep 17 00:00:00 2001 +From: Mark Adler +Date: Sat, 2 Jul 2022 14:35:04 -0700 +Subject: [PATCH] Be more liberal in the acceptance of data descriptors. + +Previously the zip64 flag determined the size of the lengths in the +data descriptor. This is compliant with the zip format. However, a +bug in the Java zip library results in an incorrect setting of that +flag. This commit permits either 32-bit or 64-bit lengths, auto- +detecting which it is, which works around the Java bug. +--- + extract.c | 146 +++++++++++++++++++++++++++++++++++++++++++++--------- + 1 file changed, 123 insertions(+), 23 deletions(-) + +diff --git a/extract.c b/extract.c +index 878817d..b1c74df 100644 +--- a/extract.c ++++ b/extract.c +@@ -2173,30 +2173,130 @@ static int extract_or_test_member(__G) /* return PK-type error code */ + undefer_input(__G); + + if ((G.lrec.general_purpose_bit_flag & 8) != 0) { +- /* skip over data descriptor (harder than it sounds, due to signature +- * ambiguity) +- */ +-# define SIG 0x08074b50 +-# define LOW 0xffffffff +- uch buf[12]; +- unsigned shy = 12 - readbuf((char *)buf, 12); +- ulg crc = shy ? 0 : makelong(buf); +- ulg clen = shy ? 0 : makelong(buf + 4); +- ulg ulen = shy ? 0 : makelong(buf + 8); /* or high clen if ZIP64 */ +- if (crc == SIG && /* if not SIG, no signature */ +- (G.lrec.crc32 != SIG || /* if not SIG, have signature */ +- (clen == SIG && /* if not SIG, no signature */ +- ((G.lrec.csize & LOW) != SIG || /* if not SIG, have signature */ +- (ulen == SIG && /* if not SIG, no signature */ +- (G.pInfo->zip64 ? G.lrec.csize >> 32 : G.lrec.ucsize) != SIG +- /* if not SIG, have signature */ +- ))))) +- /* skip four more bytes to account for signature */ +- shy += 4 - readbuf((char *)buf, 4); +- if (G.pInfo->zip64) +- shy += 8 - readbuf((char *)buf, 8); /* skip eight more for ZIP64 */ +- if (shy) ++ // Skip over the data descriptor. We need to correctly position the ++ // read pointer after the data descriptor for the proper detection of ++ // overlapped zip file components. ++ // ++ // We need to resolve an ambiguity over four possible data descriptor ++ // formats. We check for all four, and pick the longest match. The data ++ // descriptor can have a signature or not, and it can use four or ++ // eight-byte lengths. The zip format requires resolving the ambiguity ++ // of a signature or not, but it uses the zip64 flag to determine ++ // whether the lengths are four or eight bytes. However there is a bug ++ // in the Java zip library that applies the wrong value of that flag. ++ // This works around that bug by always trying both length formats. ++ // ++ // So why the longest match? And does this resolve the ambiguity? No, ++ // it doesn't definitively resolve the ambiguity. However choosing the ++ // longest match at least resolves it for a normal zip file, where the ++ // bytes following the data descriptor must be another zip signature ++ // that is not a data descriptor signature. There are a few specific ++ // cases for which more than one of the formats will match the given ++ // CRC and lengths. The most plausible is between four and eight-byte ++ // lengths, either with or without a signature. That only occurs for an ++ // entry with an uncompressed size of zero. We consider the data ++ // descriptor to be a vector of four-byte values. Then the possible ++ // data descriptors are [(s) 0 c 0] and [(s) 0 c 0 0 0], where (s) is ++ // the optional signature, and c is the compressed length. c would be ++ // two for the Deflate compressed data format. These look the same, so ++ // if the file contains [(s) 0 c 0 0 0], then we cannot discriminate ++ // them. However if the data descriptor was intended to be [(s) 0 c 0], ++ // then it has been followed by eight zero bytes in the zip file for ++ // some reason. For a normal zip file this cannot be the case. The data ++ // descriptor would always be immediately followed by another zip file ++ // signature, which is four bytes that are not zeros. The other cases ++ // where more than one format matches are vanishingly unlikely, but the ++ // longest match strategy resolves those as well in a normal zip file. ++ // Those pairs are [s s s] vs. [s s s s], [s s s] vs. [s s s 0 s 0], ++ // and [s s s s s] vs. [s s s s s s]. For all, s is the signature for a ++ // data descriptor. For the first two we have an entry whose CRC, ++ // compressed length, and uncompressed length are all equal (!), and ++ // are all equal to the signature (!!). If this occurs, clearly someone ++ // is messing with us. However the strategy works nonetheless. We see ++ // that if the shorter descriptor, [s s s] were what was intended, then ++ // it has been followed by either four zero bytes or a data descriptor ++ // signature. Neither can occur for a normal zip file, where it must be ++ // followed by a signature that is not a data descriptor signature. So ++ // the longest match is the correct choice. The final case is outright ++ // insane, since the compressed and uncompressed lengths are the data ++ // descriptor signature repeated twice to make a 64-bit length, which ++ // is about 6e17. The largest drive available as I write this is 100TB, ++ // which is one six thousandth of that length. If I apply Moore's law ++ // to drive capacity, we might get to 6e17 about 25 years from now. If ++ // this code is still in use then (I've seen other code I've written in ++ // use for over 30 years), then we're still in luck. A data descriptor ++ // cannot be followed by a data descriptor signature in a normal zip ++ // file. The longest match strategy continues to work. ++ // ++ // So what is a not normal zip file, where these assumptions might fall ++ // apart? zip files have been used in a non-standard way as a poor ++ // substitute for a file system, with entries deleted and perhaps ++ // others replacing them partially, with fragmented zip files being the ++ // result. Then all bets are off as to what might or might not follow a ++ // data descriptor. Though if this sort of data descriptor ambiguity ++ // falls in one of those gaps, then there should be no adverse ++ // consequences for picking the unintended one. ++ int len = 0; ++# define SIG 0x08074b50 // optional data descriptor signature ++#ifdef LARGE_FILE_SUPPORT ++ uch buf[24]; ++ int got = readbuf((char *)buf, sizeof(buf)); ++ if (got >= 24 && makelong(buf) == SIG && ++ makelong(buf + 4) == G.lrec.crc32 && ++ makeint64(buf + 8) == G.lrec.csize && ++ makeint64(buf + 16) == G.lrec.ucsize) ++ // Have a data descriptor with a signature and 64-bit lengths. ++ len = 24; ++ else if (got >= 20 && makelong(buf) == G.lrec.crc32 && ++ makeint64(buf + 4) == G.lrec.csize && ++ makeint64(buf + 12) == G.lrec.ucsize) ++ // Have a data descriptor with no signature and 64-bit lengths. ++ len = 20; ++ else if ((G.lrec.csize >> 32) == 0 && (G.lrec.ucsize >> 32) == 0) ++ // Both lengths are short enough to fit in 32 bits. ++#else ++ uch buf[16]; ++ int got = readbuf((char *)buf, sizeof(buf)); ++#endif ++ { ++ if (got >= 16 && makelong(buf) == SIG && ++ makelong(buf + 4) == G.lrec.crc32 && ++ makelong(buf + 8) == G.lrec.csize && ++ makelong(buf + 12) == G.lrec.ucsize) ++ // Have a data descriptor with a signature and 32-bit lengths. ++ len = 16; ++ else if (got >= 12 && makelong(buf) == G.lrec.crc32 && ++ makelong(buf + 4) == G.lrec.csize && ++ makelong(buf + 8) == G.lrec.ucsize) ++ // Have a data descriptor with no signature and 32-bit lengths. ++ len = 12; ++ } ++ if (len == 0) ++ // There is no data descriptor that matches the entry CRC and ++ // length values. + error = PK_ERR; ++ ++ // Back up got-len bytes, to position the read pointer after the data ++ // descriptor. Or to where the data descriptor was supposed to be, in ++ // the event none was found. ++ int back = got - len; ++ if (G.incnt + back > INBUFSIZ) { ++ // Need to load the preceding buffer. We've been here before. ++ G.cur_zipfile_bufstart -= INBUFSIZ; ++#ifdef USE_STRM_INPUT ++ zfseeko(G.zipfd, G.cur_zipfile_bufstart, SEEK_SET); ++#else /* !USE_STRM_INPUT */ ++ zlseek(G.zipfd, G.cur_zipfile_bufstart, SEEK_SET); ++#endif /* ?USE_STRM_INPUT */ ++ read(G.zipfd, (char *)G.inbuf, INBUFSIZ); ++ G.incnt -= INBUFSIZ - back; ++ G.inptr += INBUFSIZ - back; ++ } ++ else { ++ // Back up within current buffer. ++ G.incnt += back; ++ G.inptr -= back; ++ } + } + + return error; diff --git a/unzip-zipbomb-switch.patch b/unzip-zipbomb-switch.patch index c6d33c0..e355afd 100644 --- a/unzip-zipbomb-switch.patch +++ b/unzip-zipbomb-switch.patch @@ -137,26 +137,13 @@ index 878817d..3e58071 100644 - if ((G.lrec.general_purpose_bit_flag & 8) != 0) { + if (uO.zipbomb == TRUE) { + if ((G.lrec.general_purpose_bit_flag & 8) != 0) { - /* skip over data descriptor (harder than it sounds, due to signature - * ambiguity) - */ -@@ -2189,16 +2196,16 @@ static int extract_or_test_member(__G) /* return PK-type error code */ - ((G.lrec.csize & LOW) != SIG || /* if not SIG, have signature */ - (ulen == SIG && /* if not SIG, no signature */ - (G.pInfo->zip64 ? G.lrec.csize >> 32 : G.lrec.ucsize) != SIG -- /* if not SIG, have signature */ -+ /* if not SIG, have signature */ - ))))) -- /* skip four more bytes to account for signature */ -- shy += 4 - readbuf((char *)buf, 4); -+ /* skip four more bytes to account for signature */ -+ shy += 4 - readbuf((char *)buf, 4); - if (G.pInfo->zip64) -- shy += 8 - readbuf((char *)buf, 8); /* skip eight more for ZIP64 */ -+ shy += 8 - readbuf((char *)buf, 8); /* skip eight more for ZIP64 */ - if (shy) -- error = PK_ERR; -+ error = PK_ERR; + // Skip over the data descriptor. We need to correctly position the + // read pointer after the data descriptor for the proper detection of + // overlapped zip file components. +@@ -2189,8 +2196,8 @@ static int extract_or_test_member(__G) /* return PK-type error code */ + G.incnt += back; + G.inptr -= back; + } + } } - diff --git a/unzip.spec b/unzip.spec index 2678116..fdc7601 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 67%{?dist} +Release: 68%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -70,10 +70,11 @@ Patch29: unzip-zipbomb-manpage.patch Patch30: unzip-zipbomb-part4.patch Patch31: unzip-zipbomb-part5.patch Patch32: unzip-zipbomb-part6.patch -Patch33: unzip-zipbomb-switch.patch -Patch34: unzip-gnu89-build.patch -Patch35: unzip-6.0-wcstombs-fortify.patch +Patch33: unzip-zipbomb-part7.patch +Patch34: unzip-zipbomb-switch.patch +Patch35: unzip-gnu89-build.patch +Patch36: unzip-6.0-wcstombs-fortify.patch URL: http://infozip.sourceforge.net BuildRequires: make BuildRequires: bzip2-devel, gcc @@ -127,6 +128,7 @@ a zip archive. %patch -P33 -p1 %patch -P34 -p1 %patch -P35 -p1 +%patch -P36 -p1 %build # IZ_HAVE_UXUIDGID is needed for right functionality of unzip -X @@ -145,6 +147,10 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Wed Aug 20 2025 Jakub Martisko - 6.0-68 +- Another zipmbomb patch +Resolves: rhbz#2360938 + * Fri Jul 25 2025 Fedora Release Engineering - 6.0-67 - Rebuilt for https://fedoraproject.org/wiki/Fedora_43_Mass_Rebuild From dcc10bc2ce9c47e15c3b130f30da5408461219c9 Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Sat, 17 Jan 2026 19:38:54 +0000 Subject: [PATCH 08/10] Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild --- unzip.spec | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/unzip.spec b/unzip.spec index fdc7601..479a80f 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 68%{?dist} +Release: 69%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -147,6 +147,9 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Sat Jan 17 2026 Fedora Release Engineering - 6.0-69 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild + * Wed Aug 20 2025 Jakub Martisko - 6.0-68 - Another zipmbomb patch Resolves: rhbz#2360938 From a0057847898ec101d06ea53ceb8bf9ed82cead24 Mon Sep 17 00:00:00 2001 From: Fedora Release Engineering Date: Fri, 17 Jul 2026 08:13:31 +0000 Subject: [PATCH 09/10] Rebuilt for https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild --- unzip.spec | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/unzip.spec b/unzip.spec index 479a80f..3510559 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 69%{?dist} +Release: 70%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -147,6 +147,9 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Fri Jul 17 2026 Fedora Release Engineering - 6.0-70 +- Rebuilt for https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild + * Sat Jan 17 2026 Fedora Release Engineering - 6.0-69 - Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild From 5787660118b7f462b8ff39151b773bf64fec6400 Mon Sep 17 00:00:00 2001 From: Jakub Martisko Date: Mon, 27 Jul 2026 11:44:42 +0200 Subject: [PATCH 10/10] Port several downstream patches from rhel Fixes for: - RHEL-86228, RHEL-45997 - Some coverity issues - CVE-2022-0529 and CVE-2022-0530 (thanks Stewart Smith for head up about these) --- unzip-6.0-CVE-2022-0529-and-0530.patch | 170 ++++++++++++++++++ unzip-6.0-RHEL-86228.patch | 19 ++ ....0-fix-warning-messages-on-big-files.patch | 15 ++ unzip-6.0-sast.patch | 11 ++ unzip.spec | 20 ++- 5 files changed, 234 insertions(+), 1 deletion(-) create mode 100644 unzip-6.0-CVE-2022-0529-and-0530.patch create mode 100644 unzip-6.0-RHEL-86228.patch create mode 100644 unzip-6.0-fix-warning-messages-on-big-files.patch create mode 100644 unzip-6.0-sast.patch diff --git a/unzip-6.0-CVE-2022-0529-and-0530.patch b/unzip-6.0-CVE-2022-0529-and-0530.patch new file mode 100644 index 0000000..2b84b96 --- /dev/null +++ b/unzip-6.0-CVE-2022-0529-and-0530.patch @@ -0,0 +1,170 @@ +From: Steven M. Schweda +Subject: Fix for CVE-2022-0529 and CVE-2022-0530 +Bug-Debian: https://bugs.debian.org/1010355 +X-Debian-version: 6.0-27 + +--- a/fileio.c ++++ b/fileio.c +@@ -171,8 +171,10 @@ + static ZCONST char Far FilenameTooLongTrunc[] = + "warning: filename too long--truncating.\n"; + #ifdef UNICODE_SUPPORT ++ static ZCONST char Far UFilenameCorrupt[] = ++ "error: Unicode filename corrupt.\n"; + static ZCONST char Far UFilenameTooLongTrunc[] = +- "warning: Converted unicode filename too long--truncating.\n"; ++ "warning: Converted Unicode filename too long--truncating.\n"; + #endif + static ZCONST char Far ExtraFieldTooLong[] = + "warning: extra field too long (%d). Ignoring...\n"; +@@ -2361,16 +2363,30 @@ + /* convert UTF-8 to local character set */ + fn = utf8_to_local_string(G.unipath_filename, + G.unicode_escape_all); +- /* make sure filename is short enough */ +- if (strlen(fn) >= FILNAMSIZ) { +- fn[FILNAMSIZ - 1] = '\0'; ++ ++ /* 2022-07-22 SMS, et al. CVE-2022-0530 ++ * Detect conversion failure, emit message. ++ * Continue with unconverted name. ++ */ ++ if (fn == NULL) ++ { + Info(slide, 0x401, ((char *)slide, +- LoadFarString(UFilenameTooLongTrunc))); +- error = PK_WARN; ++ LoadFarString(UFilenameCorrupt))); ++ error = PK_ERR; ++ } ++ else ++ { ++ /* make sure filename is short enough */ ++ if (strlen(fn) >= FILNAMSIZ) { ++ fn[FILNAMSIZ - 1] = '\0'; ++ Info(slide, 0x401, ((char *)slide, ++ LoadFarString(UFilenameTooLongTrunc))); ++ error = PK_WARN; ++ } ++ /* replace filename with converted UTF-8 */ ++ strcpy(G.filename, fn); ++ free(fn); + } +- /* replace filename with converted UTF-8 */ +- strcpy(G.filename, fn); +- free(fn); + } + # endif /* UNICODE_WCHAR */ + if (G.unipath_filename != G.filename_full) +--- a/process.c ++++ b/process.c +@@ -222,6 +222,8 @@ + "\nwarning: Unicode Path version > 1\n"; + static ZCONST char Far UnicodeMismatchError[] = + "\nwarning: Unicode Path checksum invalid\n"; ++ static ZCONST char Far UFilenameTooLongTrunc[] = ++ "warning: filename too long (P1) -- truncating.\n"; + #endif + + +@@ -1915,7 +1917,7 @@ + Sets both local header and central header fields. Not terribly clever, + but it means that this procedure is only called in one place. + +- 2014-12-05 SMS. ++ 2014-12-05 SMS. (oCERT.org report.) CVE-2014-8141. + Added checks to ensure that enough data are available before calling + makeint64() or makelong(). Replaced various sizeof() values with + simple ("4" or "8") constants. (The Zip64 structures do not depend +@@ -1947,7 +1949,7 @@ + + if (eb_id == EF_PKSZ64) + { +- int offset = EB_HEADSIZE; ++ unsigned offset = EB_HEADSIZE; + + if ((G.crec.ucsize == Z64FLGL) || (G.lrec.ucsize == Z64FLGL)) + { +@@ -2046,7 +2049,7 @@ + } + if (eb_id == EF_UNIPATH) { + +- int offset = EB_HEADSIZE; ++ unsigned offset = EB_HEADSIZE; + ush ULen = eb_len - 5; + ulg chksum = CRCVAL_INITIAL; + +@@ -2504,16 +2507,17 @@ + int state_dependent; + int wsize = 0; + int max_bytes = MB_CUR_MAX; +- char buf[9]; ++ char buf[ MB_CUR_MAX+ 1]; /* ("+1" not really needed?) */ + char *buffer = NULL; + char *local_string = NULL; ++ size_t buffer_size; /* CVE-2022-0529 */ + + for (wsize = 0; wide_string[wsize]; wsize++) ; + + if (max_bytes < MAX_ESCAPE_BYTES) + max_bytes = MAX_ESCAPE_BYTES; +- +- if ((buffer = (char *)malloc(wsize * max_bytes + 1)) == NULL) { ++ buffer_size = wsize * max_bytes + 1; /* Reused below. */ ++ if ((buffer = (char *)malloc( buffer_size)) == NULL) { + return NULL; + } + +@@ -2551,8 +2555,28 @@ + } else { + /* no MB for this wide */ + /* use escape for wide character */ +- char *escape_string = wide_to_escape_string(wide_string[i]); +- strcat(buffer, escape_string); ++ size_t buffer_len; ++ size_t escape_string_len; ++ char *escape_string; ++ int err_msg = 0; ++ ++ escape_string = wide_to_escape_string(wide_string[i]); ++ buffer_len = strlen( buffer); ++ escape_string_len = strlen( escape_string); ++ ++ /* Append escape string, as space allows. */ ++ /* 2022-07-18 SMS, et al. CVE-2022-0529 */ ++ if (escape_string_len > buffer_size- buffer_len- 1) ++ { ++ escape_string_len = buffer_size- buffer_len- 1; ++ if (err_msg == 0) ++ { ++ err_msg = 1; ++ Info(slide, 0x401, ((char *)slide, ++ LoadFarString( UFilenameTooLongTrunc))); ++ } ++ } ++ strncat( buffer, escape_string, escape_string_len); + free(escape_string); + } + } +@@ -2604,9 +2628,18 @@ + ZCONST char *utf8_string; + int escape_all; + { +- zwchar *wide = utf8_to_wide_string(utf8_string); +- char *loc = wide_to_local_string(wide, escape_all); +- free(wide); ++ zwchar *wide; ++ char *loc = NULL; ++ ++ wide = utf8_to_wide_string( utf8_string); ++ ++ /* 2022-07-25 SMS, et al. CVE-2022-0530 */ ++ if (wide != NULL) ++ { ++ loc = wide_to_local_string( wide, escape_all); ++ free( wide); ++ } ++ + return loc; + } + diff --git a/unzip-6.0-RHEL-86228.patch b/unzip-6.0-RHEL-86228.patch new file mode 100644 index 0000000..25c2fbb --- /dev/null +++ b/unzip-6.0-RHEL-86228.patch @@ -0,0 +1,19 @@ +From: Roy Tam +Subject: Handle Microsoft ZIP64 files by ignoring invalid "Total number of disks" field +Origin: https://sourceforge.net/p/infozip/bugs/42/ +Bug: https://sourceforge.net/p/infozip/bugs/42/ +Bug-Debian: https://bugs.debian.org/1064000 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/unzip/+bug/2051952 +X-Debian-version: 6.0-29 + +--- a/process.c ++++ b/process.c +@@ -1281,7 +1281,7 @@ + fprintf(stdout,"\nnumber of disks (ECR) %u, (ECLOC64) %lu\n", + G.ecrec.number_this_disk, ecloc64_total_disks); fflush(stdout); + #endif +- if ((G.ecrec.number_this_disk != 0xFFFF) && ++ if ((G.ecrec.number_this_disk != 0xFFFF) && ecloc64_total_disks && + (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) { + /* Note: For some unknown reason, the developers at PKWARE decided to + store the "zip64 total disks" value as a counter starting from 1, diff --git a/unzip-6.0-fix-warning-messages-on-big-files.patch b/unzip-6.0-fix-warning-messages-on-big-files.patch new file mode 100644 index 0000000..55a115a --- /dev/null +++ b/unzip-6.0-fix-warning-messages-on-big-files.patch @@ -0,0 +1,15 @@ +From: "Steven M. Schweda" +Subject: Fix lame code in fileio.c +Bug-Debian: https://bugs.debian.org/929502 +X-Debian-version: 6.0-23 + +--- a/fileio.c ++++ b/fileio.c +@@ -2477,6 +2477,7 @@ + */ + return (((zusz_t)sig[7]) << 56) + + (((zusz_t)sig[6]) << 48) ++ + (((zusz_t)sig[5]) << 40) + + (((zusz_t)sig[4]) << 32) + + (zusz_t)((((ulg)sig[3]) << 24) + + (((ulg)sig[2]) << 16) diff --git a/unzip-6.0-sast.patch b/unzip-6.0-sast.patch new file mode 100644 index 0000000..71b7cb9 --- /dev/null +++ b/unzip-6.0-sast.patch @@ -0,0 +1,11 @@ +--- a/envargs.c 2005-03-04 03:23:38.000000000 +0100 ++++ b/envargs.c 2024-11-26 13:17:22.289650230 +0100 +@@ -118,7 +118,7 @@ + + /* remove escape characters */ + while ((argstart = MBSCHR(argstart, '\\')) != (char *)NULL) { +- strcpy(argstart, argstart + 1); ++ memmove(argstart, argstart + 1, strlen(argstart + 1) + 1); + if (*argstart) + ++argstart; + } diff --git a/unzip.spec b/unzip.spec index 3510559..ed8ee48 100644 --- a/unzip.spec +++ b/unzip.spec @@ -6,7 +6,7 @@ Summary: A utility for unpacking zip files Name: unzip Version: 6.0 -Release: 70%{?dist} +Release: 71%{?dist} License: Info-ZIP Source: http://downloads.sourceforge.net/infozip/unzip60.tar.gz @@ -75,6 +75,15 @@ Patch34: unzip-zipbomb-switch.patch Patch35: unzip-gnu89-build.patch Patch36: unzip-6.0-wcstombs-fortify.patch + +Patch37: unzip-6.0-fix-warning-messages-on-big-files.patch +Patch38: unzip-6.0-sast.patch +Patch39: unzip-6.0-RHEL-86228.patch +#From Debian +Patch40: unzip-6.0-CVE-2022-0529-and-0530.patch + + + URL: http://infozip.sourceforge.net BuildRequires: make BuildRequires: bzip2-devel, gcc @@ -129,6 +138,10 @@ a zip archive. %patch -P34 -p1 %patch -P35 -p1 %patch -P36 -p1 +%patch -P37 -p1 +%patch -P38 -p1 +%patch -P39 -p1 +%patch -P40 -p1 %build # IZ_HAVE_UXUIDGID is needed for right functionality of unzip -X @@ -147,6 +160,11 @@ make -f unix/Makefile prefix=$RPM_BUILD_ROOT%{_prefix} MANDIR=$RPM_BUILD_ROOT%{_ %{_mandir}/*/* %changelog +* Wed Jul 22 2026 Jakub Martisko - 6.0-71 +- Port some RHEL downstream patches to fedora +- Fixes for RHEL-86228, RHEL-45997 + some issues found by coverity and other scans +- Fixes for CVE-2022-0529 and 2022-0530 (Thanks Stewart Smith for the Heads up about these) + * Fri Jul 17 2026 Fedora Release Engineering - 6.0-70 - Rebuilt for https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild