A use-after-free vulnerability was found in libpng's sequential reader (versions 1.6.0 through 1.6.58). When an application calls png_read_end after png_read_info without first reading image rows, crafted zTXt, iTXt, or iCCP chunks can cause libpng to abandon decompression while zlib still expects more input, leaving a stale pointer and non-zero input count in the zlib stream. When png_read_end runs, it resumes decompression from that dangling pointer.

Two variants exist:
1. Heap use-after-free (zTXt/iTXt): The stale pointer references libpng's chunk read buffer. If a subsequent chunk requires more space, the buffer gets freed, and the later read becomes a heap use-after-free.
2. Stack use-after-return (iCCP): The pointer references local arrays of png_handle_iCCP, resulting in a stack use-after-return read.

Decompression can be abandoned due to invalid window size in the zlib header, decompressed data exceeding libpng's size limit, or an ICC profile that fails validation.

The dangling pointer is read-only; decompressed bytes go to a discarded scratch buffer, so no data is disclosed or corrupted. The worst outcome is a crash when freed heap memory is inaccessible.

Applications are vulnerable if they use the sequential read API and call png_read_end before any of png_read_update_info, png_start_read_image, png_read_row, png_read_rows, or png_read_image. Applications that read image rows before calling png_read_end, or use png_read_png, the simplified API (png_image_*), or the progressive reader (png_process_data) are not affected.

Upstream advisory: https://github.com/pnggroup/libpng/security/advisories/GHSA-qvg3-h654-xq3j
Upstream fix: https://github.com/pnggroup/libpng/commit/aa77ef38c17ab2fc1b41bec09fb973c6a386641d