Hi Theo, Theo de Raadt wrote on Thu, Apr 16, 2020 at 04:23:19PM -0600:
> There is more than one copy if libz in the tree. Good point. > Please fix them all. The code in /usr/src/gnu/usr.bin/cvs/zlib/gzio.c appears to be very different (about three years older) and from code inspection, that version doesn't appear to suffer from this bug. The code in /usr/src/sys/lib/libz/ is even more different and doesn't have a gzio.c file, doesn't have a check_header() function, doesn't have a gz_stream data type, doesn't contain the word "transparent" anywhere, so i see now way how it could have a bug that would be in any way similar. The directories /usr/src/sys/arch/*/stand/libz/ seem to contain specialized build systems for /usr/src/sys/lib/libz/, but no copies of code. The directory /usr/src/gnu/llvm/utils/gn/build/libs/zlib/ appears to contain some build system glue, but no copies of code either. The directory /usr/src/gnu/usr.bin/perl/cpan/Compress-Raw-Zlib/zlib-src/ is yet again very different from the others, but like the kernel, has none of the features occurring in the vicinity of this bug. The file /usr/src/lib/libcrypto/comp/c_zlib.c and the files around it appear to be completely undocumented even though they are compiled in, so i'm not quite sure what they are supposed to do. Either way, they look entirely different. The file /usr/src/sys/dev/pci/drm/include/linux/zlib.h is completely empty. The code in /usr/xenocara/lib/freetype/src/gzip/ is a completely different codebase written by other authors. So my impression is that this bug is unique and only occurs in /usr/src/lib/libz/. Yours, Ingo
