- 12 9月, 2016 1 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
- 04 9月, 2016 1 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
- 03 9月, 2016 1 次提交
-
-
由 John Bowler 提交于
Because png_handle_pCAL has allocated memory to free. Signed-off-by: NJohn Bowler <jbowler@acm.org>
-
- 02 9月, 2016 3 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
-
由 John Bowler 提交于
-
- 01 9月, 2016 3 次提交
-
-
由 John Bowler 提交于
When an input file contains a zero length IDAT and pngfix is not applying the IDAT rechunking (--max) option pngfix will go into a loop writing the zero length IDAT for ever. This is a fairly minor issue for interactive use; zero length IDAT is very rare, the problem is obvious (pngfix hangs) and the fix (use --max, or --max=4096 etc), while not obvious, is easy. For non-interactive use, e.g. trying to automatically repair a PNG that cannot be read by libpng, there are security consequences: 1) pngfix hangs. This may permit a DoS attack. 2) When the --out option is used pngfix will just keep writing. This is a very likely DoS scenario. Signed-off-by: NJohn Bowler <jbowler@acm.org>
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
- 31 8月, 2016 2 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
- 30 8月, 2016 7 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
由 Mandar Sahastrabuddhe 提交于
1. png_read_filter_row_sub4_msa 2. png_read_filter_row_avg4_msa 3. png_read_filter_row_paeth4_msa 4. png_read_filter_row_sub3_msa 5. png_read_filter_row_avg3_msa 6. png_read_filter_row_paeth3_msa Signed-off-by: NMandar Sahastrabuddhe <Mandar.Sahastrabuddhe@imgtec.com>
-
由 Mandar Sahastrabuddhe 提交于
Update from original
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
- 29 8月, 2016 4 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
由 Mandar Sahastrabuddhe 提交于
Also added one msa optimized function: png_read_filter_row_up_msa Signed-off-by: NMandar Sahastrabuddhe <Mandar.Sahastrabuddhe@imgtec.com>
-
- 19 8月, 2016 3 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
- 17 8月, 2016 2 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
- 14 8月, 2016 1 次提交
-
-
由 Glenn Randers-Pehrson 提交于
Moved it from bin_PROGRAMS to check_PROGRAMS in Makefile.am so it will be built but not installed.
-
- 12 8月, 2016 4 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
chunk reading.
-
- 11 8月, 2016 4 次提交
-
-
由 Glenn Randers-Pehrson 提交于
now that iCCP profile_length honors PNG_USER_CHUNK_MALLOC_MAX.
-
-
由 John Bowler 提交于
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: NJohn Bowler <jbowler@acm.org>
-
由 Glenn Randers-Pehrson 提交于
png_error() on failure. Reject oversized iCCP profile immediately.
-
- 04 8月, 2016 2 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-
- 03 8月, 2016 2 次提交
-
-
由 Glenn Randers-Pehrson 提交于
-
由 Glenn Randers-Pehrson 提交于
-