Bug 2554045 - CVE-2026-46675 java-latest-openjdk: libpng: Use-after-free in sequential reader when png_read_end called without reading image rows [fedora-all]
Summary: CVE-2026-46675 java-latest-openjdk: libpng: Use-after-free in sequential read...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: java-latest-openjdk
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Petra Alice Mikova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: {"flaws": ["870155ff-6cf0-4529-a848-4...
Depends On:
Blocks: CVE-2026-46675
TreeView+ depends on / blocked
 
Reported: 2026-10-16 12:17 UTC by Laura Pardo
Modified: 2026-10-16 12:17 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Laura Pardo 2026-10-16 12:17:37 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

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


Note You need to log in before you can comment on or make changes to this bug.