The code now validates the ICC profile length against the user chunk limit
before the buffer is allocated, as opposed to doing it while the buffer is read.
This removes the potential to consume virtual address space with a carefully
crafted ICC profile; only an issue on 32-bit systems where a valid profile can
be up to 2^32-4 bytes in length. libpng never writes beyond the application
supplied limit, but previously it did allocate a buffer of the size specified in
the profile header. The exploitability of this is almost zero; the address
space is released as soon as the PNG read completes.
Also clean up PNG_DEBUG compile of pngtest.c.
Signed-off-by: John Bowler <jbowler@acm.org>
The fixed size buffer for the file name being processed could have a byte
written beyond the end; a bug where the test was updated without changing the
size of the buffer. This commit reduces the buffer to the system maximum.
png_getrowbytes could, in theory, return 0; probably only if there is a bug in
libpng but the code now checks.
Signed-off-by: John Bowler <jbowler@acm.org>
In libpng 1.7 pngimage needs to check PNG_WRITE_PNG_SUPPORTED (new in 1.7), not
PNG_WRITE_SUPPORTED because png_write_png can be disabled without disabling
PNG_WRITE_SUPPORTED. Copied the approach from 1.6 pngcp.c (so this still works
in 1.6 as well.)
If PNG_PNGCP_TIMING_SUPPORTED is defined maximal resolution CPU time logging of
png_read_png and png_write_png is enabled via the --time command line option.
This is not on by default but is enabled by contrib/conftests/pngcp.dfa
Signed-off-by: John Bowler <jbowler@acm.org>
This adds pngcp to the build together with a pngcp.dfa configuration test; the
test revealed some configuration bugs which are fixed by corrections to the
_SUPPORTED macros.
pngcp builds on all tested configurations and a number of bugs have been fixed
to make this happen relative to the version in libpng 1.7 contrib/examples.
pngcp.dfa will have to be different for 1.7 but pngcp.c should work fine (not
yet tested). pngcp itself is still missing a usage message; this is a
preliminary version, although since it behaves the same way as 'cp' most unoids
shouldn't have a problem using it correctly.
Signed-off-by: John Bowler <jbowler@acm.org>
