El 25/7/24 a las 17:12, Adam Sampson escribió:
If zip 3.0-14 is built with _FORTIFY_SOURCE=3 (GCC 14.1, glibc 2.40),
this can happen when compressing a file with non-ASCII characters in its
UTF-8 name:
$ echo -n "There’s a Baby in the House.flac" | od -c
0000000 T h e r e 342 200 231 s a B a b y
0000020 i n t h e H o u s e . f l
0000040 a c
$ zip /tmp/t.zip "There’s a Baby in the House.flac"
*** buffer overflow detected ***: terminated
The problem is in local_to_wide_string, where mbstowcs is being run with
the UTF-8 source length rather than the widechar destination length --
this correctly trips a fortify error because GCC 14 can infer the actual
size of the destination.
Hello. A very similar problem was reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093629
In theory, this was already fixed by Fedora here:
https://src.fedoraproject.org/rpms/zip/raw/f41/f/buffer_overflow.patch
in a slightly different way:
--- a/fileio.c
+++ b/fileio.c
@@ -3502,7 +3502,7 @@
if ((wc_string = (wchar_t *)malloc((wsize + 1) * sizeof(wchar_t))) == NULL) {
ZIPERR(ZE_MEM, "local_to_wide_string");
}
- wsize = mbstowcs(wc_string, local_string, strlen(local_string) + 1);
+ wsize = mbstowcs(wc_string, local_string, wsize + 1);
wc_string[wsize] = (wchar_t) 0;
/* in case wchar_t is not zwchar */
I plan to do that in zip 3.0-15.
If that's not enough, please specify the exact way in which I
can reproduce the error using Debian unstable.
I tried using this line in debian/rules:
CPPFLAGS := -Wdate-time -D_FORTIFY_SOURCE=3
but did not notice any change in behavior.
Thanks.
