Bug 2553266 (CVE-2026-46675)

Summary:	CVE-2026-46675 libpng: libpng: Use-after-free in sequential reader when png_read_end called without reading image rows
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	ahughes, akhatavk, amctagga, aoconnor, aos-team-art-private, asdas, bniver, dpaolell, fferrari, flucifre, gmeno, gotiwari, groman, jdelft, jhorak, jupierce, kaycoth, khosford, lgarciaa, mbenjamin, mbiarnes, mhackett, mtorre, mvyas, pjindal, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, sostapov, suppawar, tfitzsim, vereddy, vlaad, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in libpng. A remote attacker could exploit this vulnerability to cause a Denial of Service (DoS) by supplying a specially crafted PNG image. Incomplete decompression of certain metadata chunks can leave a dangling pointer in the library's internal decompression state. When an application finishes processing without reading the image rows, libpng attempts to read from this invalid memory location, resulting in an application crash.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2554045, 2554046, 2554048, 2554049, 2554050, 2554051, 2554052, 2554053, 2554055, 2554056, 2554057, 2554058
Bug Blocks:

Description OSIDB Bzimport 2026-10-15 10:13:43 UTC

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