[Zlib-devel] apparent 1.2.7 windowBits == 0 (autodetection) bug

[Mark Adler]

On Apr 6, 2013, at 3:04 PM, Greg Roelofs <newt at pobox.com> wrote:
> Someone just posted an error report to the libpng list about the following
> icons triggering an "invalid distance too far back" error:
> 
>   http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/network-manager-applet-0.9.8.0.tar.xz
> 
>   -rw-rw-r-- 500/500         470 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-75.png
>   -rw-rw-r-- 500/500         492 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-50.png
>   -rw-rw-r-- 500/500         496 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-25.png
>   -rw-rw-r-- 500/500         409 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-100.png
>   -rw-rw-r-- 500/500         490 2009-12-23 10:30 network-manager-applet-0.9.8.0/icons/22/nm-signal-00.png

Those files are in fact broken, in that the zlib header says that a 512-byte window is ok, but the maximum distance found in all of them is 1419.  That would require at least a 2048-byte window.

For zlib to detect this, it has to be compiled with INFLATE_STRICT defined.  The default compilation of zlib does not check for strict compliance of the compressed data to the specified window size.

zlib will report an error if it has to look further back than the sliding window it has retained, but if it has the data that far back available, it will use it.  These files are one example of that case, where there would very likely be enough output space provided to decompress in a single step (all are less than 2K decompressed), so that a sliding window is never even created.  In that case, all of the output is available, and zlib can correctly decompress the input, even if windowBits == 9 is specified.

As I recall, INFLATE_STRICT was added specifically at the request of the PNG community.

Mark