CVE-2019-7317: use-after-free in png_image_free()
Switch library soname from libpng16.so to libpng.so by changing the primary
name in the build. Bump major version.
ok sthen@
"libpng version 1.6.31 added png_handle_eXIf(), which has a
null-pointer-dereference bug as well as a potential memory leak. Insofar as the
function has existed for only four weeks and the chunk itself for only six,
it's unlikely there are any applications affected by it at this time, but they
might come into existence in the future. The vulnerability is fixed in version
1.6.32, released on 24 August 2017."
ok naddy@
(so build as-is fails), switching to operating on libpng16.la results in a
plist change, and the installed files from the previous package do actually
have a difference between libpng.la and libpng16.la(?!).
libpng will hang when reading images that have zero-length IDAT chunks with
the progressive (streaming) reader; a malicious web site could use this bug
to cause a (minor) denial of service. (CVE-2014-0333)
ok sthen@
this is to force pkg_add -u to pick them up because moving to PIE does change
these files but since there are no library bumps, the package signature stays
the same.
there are probably others, these are just ones I've run into. not a great
fix, and needs to be repeated when other arch move, but it's the simplest low
impact fix and I'm fed up with "relocation R_X86_64_32S can not be used
when making a shared object; recompile with -fPIC"
libpng failed to correctly handle malloc() failure for text chunks,
which can lead to memory corruption and the possibility of execution
of hostile code. (CVE-2011-3048)
1. buffer overwrite in png_rgb_to_gray (CVE-2011-2690)
2. crash in png_default_error due to use of NULL Pointer (CVE-2011-2691)
3. memory corruption when handling empty sCAL chunks (CVE-2011-2692)
API incompatibility:
"The libpng 1.5.x series finally hides the contents of the venerable
and hoary png_struct and png_info data structures inside private
(i.e., non-installed) header files. Instead of direct struct-access,
applications should be using the various png_get_xxx() and png_set_xxx()
accessor functions, which have existed for almost as long as libpng
itself."
