Debian Patches

Status for libpng1.6/1.6.39-2+deb12u1

Patch Description Author Forwarded Bugs Origin Last update
CVE-2025-64720.patch [PATCH] Fix a buffer overflow in `png_init_read_transformations`
The palette compositing code in `png_init_read_transformations` was
incorrectly applying background compositing when PNG_FLAG_OPTIMIZE_ALPHA
was set. This violated the premultiplied alpha invariant
`component <= alpha` expected by `png_image_read_composite`, causing
values that exceeded the valid range for the PNG_sRGB_FROM_LINEAR lookup
tables.

When PNG_ALPHA_OPTIMIZED is active, palette entries should contain pure
premultiplied RGB values without background compositing. The background
compositing must happen later in `png_image_read_composite` where the
actual background color from the PNG file is available.

The fix consists in introducing conditional behavior based on
PNG_FLAG_OPTIMIZE_ALPHA: when set, the code performs only
premultiplication using the formula `component * alpha + 127) / 255`
with proper gamma correction. When not set, the original background
compositing calculation based on the `png_composite` macro is preserved.

This prevents buffer overflows in `png_image_read_composite` where
out-of-range premultiplied values would cause out-of-bounds array access
in `png_sRGB_base[]` and `png_sRGB_delta[]`.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/08da33b4c88cfcd36e5a706558a8d7e0e4773643 2025-11-12
CVE-2025-64506.patch [PATCH] Fix a heap buffer overflow in `png_write_image_8bit`
The condition guarding the pre-transform path incorrectly allowed 8-bit
input data to enter `png_write_image_8bit` which expects 16-bit input.
This caused out-of-bounds reads when processing 8-bit grayscale+alpha
images (GitHub #688), or 8-bit RGB or RGB+alpha images (GitHub #746),
with the `convert_to_8bit` flag set (an invalid combination that should
bypass the pre-transform path).

The second part of the condition, i.e.

colormap == 0 && convert_to_8bit != 0

failed to verify that input was 16-bit, i.e.

linear != 0

contradicting the comment "This only applies when the input is 16-bit".

The fix consists in restructuring the condition to ensure both the
`alpha` path and the `convert_to_8bit` path require linear (16-bit)
input. The corrected condition, i.e.

linear != 0 && (alpha != 0 || display->convert_to_8bit != 0)

matches the expectation of the `png_write_image_8bit` function and
prevents treating 8-bit buffers as 16-bit data.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/2bd84c019c300b78e811743fbcddb67c9d9bf821 2025-11-07
libpng-config.patch this patch is needed to strip arch-dep bits and get a multiarch -dev package. no
CVE-2025-64505.patch [PATCH] Fix a buffer overflow in `png_do_quantize`
Allocate the quantize_index array to PNG_MAX_PALETTE_LENGTH (256 bytes)
instead of num_palette bytes. This approach matches the allocation
pattern for `palette[]`, `trans_alpha[]` and `riffled_palette[]` which
were similarly oversized in libpng 1.2.1 to prevent buffer overflows
from malformed PNG files with out-of-range palette indices.

Out-of-range palette indices `index >= num_palette` will now read
identity-mapped values from the `quantize_index` array (where index N
maps to palette entry N). This prevents undefined behavior while
avoiding runtime bounds checking overhead in the performance-critical
pixel processing loop.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/6a528eb5fd0dd7f6de1c39d30de0e41473431c37 2025-11-08
CVE-2025-65018-part1.patch [PATCH] Fix a buffer overflow in `png_image_finish_read`
Reject bit-depth mismatches between IHDR and the requested output
format. When a 16-bit PNG is processed with an 8-bit output format
request, `png_combine_row` writes using the IHDR depth before
transformation, causing writes beyond the buffer allocated via
`PNG_IMAGE_SIZE(image)`.

The validation establishes a safe API contract where
`PNG_IMAGE_SIZE(image)` is guaranteed to be sufficient across the
transformation pipeline.

Example overflow (32×32 pixels, 16-bit RGB to 8-bit RGBA):
- Input format: 16 bits/channel × 3 channels = 6144 bytes
- Output buffer: 8 bits/channel × 4 channels = 4096 bytes
- Overflow: 6144 bytes - 4096 bytes = 2048 bytes

Larger images produce proportionally larger overflows. For example,
for 256×256 pixels, the overflow is 131072 bytes.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/16b5e3823918840aae65c0a6da57c78a5a496a4d 2025-11-17
CVE-2025-65018-part2.patch [PATCH] Rearchitect the fix to the buffer overflow in `png_image_finish_read`

Undo the fix from commit 16b5e3823918840aae65c0a6da57c78a5a496a4d.
That fix turned out to be unnecessarily limiting. It rejected all
16-to-8 bit transformations, although the vulnerability only affects
interlaced PNGs where `png_combine_row` writes using IHDR bit-depth
before the transformation completes.

The proper solution is to add an intermediate `local_row` buffer,
specifically for the slow but necessary step of 16-to-8 bit conversion
of interlaced images. (The processing of non-interlaced images remains
intact, using the fast path.) We added the flag `do_local_scale` and
the function `png_image_read_direct_scaled`, following the pattern that
involves `do_local_compose`.

In conclusion:
- The 16-to-8 bit transformations of interlaced images are now safe,
as they use an intermediate buffer.
- The 16-to-8 bit transformations of non-interlaced images remain safe,
as the fast path remains unchanged.
- All our regression tests are now passing.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/218612ddd6b17944e21eda56caf8b4bf7779d1ea 2025-11-19
CVE-2025-66293-part1.patch [PATCH] Fix an out-of-bounds read in `png_image_read_composite`
Add a defensive bounds check before calling PNG_sRGB_FROM_LINEAR to
prevent reading up to 506 entries (1012 bytes) past `png_sRGB_base[]`.

For palette images with gamma, `png_init_read_transformations`
clears PNG_COMPOSE after compositing on the palette, but it leaves
PNG_FLAG_OPTIMIZE_ALPHA set. The simplified API then calls
`png_image_read_composite` with sRGB data (not linear premultiplied),
causing the index to reach 1017. (The maximum valid index is 511.)

NOTE:
This is a defensive fix that addresses the security issue (out-of-bounds
read) but *NOT* the correctness issue (wrong output). When the clamp
triggers, the affected pixels are clamped to white instead of the
correct composited color. Valid PNG images may render incorrectly with
the simplified API.

TODO:
We already know the root cause is a flag synchronization error.
For palette images with gamma, `png_init_read_transformations`
clears PNG_COMPOSE but leaves PNG_FLAG_OPTIMIZE_ALPHA set, causing
`png_image_read_composite` to misinterpret sRGB data as linear
premultiplied. However, we have yet to implement an architectural fix
that requires coordinating the simplified API with the transformation
pipeline.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/788a624d7387a758ffd5c7ab010f1870dea753a1 2025-11-29
CVE-2025-66293-part2.patch [PATCH] Finalize the fix for out-of-bounds read in `png_image_read_composite`

Following up on commit 788a624d7387a758ffd5c7ab010f1870dea753a1.

The previous commit added a defensive bounds check to address the
security issue (out-of-bounds read), but noted that the correctness
issue remained: when the clamp triggered, the affected pixels were
clamped to white instead of the correct composited color.

This commit addresses the correctness issue by fixing the flag
synchronization error identified in the previous commit's TODO:

1. In `png_init_read_transformations`:
Clear PNG_FLAG_OPTIMIZE_ALPHA when clearing PNG_COMPOSE for palette
images. This correctly signals that the data is sRGB, not linear
premultiplied.

2. In `png_image_read_composite`:
Check PNG_FLAG_OPTIMIZE_ALPHA and use the appropriate composition
formula. When set, use the existing linear composition. When cleared
(palette composition already done), use sRGB composition to match
what was done to the palette.

Retain the previous clamp to the valid range as belt-and-suspenders
protection against any other unforeseen cases.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/a05a48b756de63e3234ea6b3b938b8f5f862484a 2025-12-01

All known versions for source package 'libpng1.6'

Links