Debian Patches

Status for libpng1.6/1.6.48-1+deb13u3

Patch Description Author Forwarded Bugs Origin Last update
libpng-config.patch this patch is needed to strip arch-dep bits and get a multiarch -dev package.=================================================================== no
CVE-2025-64505.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-64506.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
CVE-2025-64720.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-65018-part1.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 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 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 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
CVE-2026-22801.patch fix: Remove incorrect truncation casts from `png_write_image_*`

The type of the row stride (`display->row_bytes`) is ptrdiff_t. Casting
to png_uint_16 before division will truncate large strides, causing
incorrect pointer arithmetic for images exceeding 65535 bytes per row.
For bottom-up images (negative stride), the truncation also corrupts
the sign, advancing the row pointer forward instead of backward.

Remove the erroneous casts and let the compiler handle the pointer
arithmetic correctly. Also replace `sizeof (png_uint_16)` with 2.

Add regression test via `pngstest --stride-extra N` where N > 32767
triggers the affected code paths.

A NOTE ABOUT HISTORY:
The original code in libpng 1.5.6 (2011) had no such casts. They were
introduced in libpng 1.6.26 (2016), likely to silence compiler warnings
on 16-bit systems where the cast would be a no-op. On 32/64-bit systems
the cast truncates the strides above 65535 and corrupts the negative
strides.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/cf155de014fc6c5cb199dd681dd5c8fb70429072 2026-01-10
CVE-2026-22695.patch Fix a heap buffer over-read in `png_image_read_direct_scaled`
Fix a regression from commit 218612ddd6b17944e21eda56caf8b4bf7779d1ea.

The function `png_image_read_direct_scaled`, introduced by the fix for
CVE-2025-65018, copies transformed row data from an intermediate buffer
(`local_row`) to the user's output buffer. The copy incorrectly used
`row_bytes` (the caller's stride) as the size parameter to memcpy, even
though `local_row` is only `png_get_rowbytes()` bytes long.

This causes a heap buffer over-read when:

1. The caller provides a padded stride (e.g., for memory alignment):
memcpy reads past the end of `local_row` by `stride - row_width`
bytes.

2. The caller provides a negative stride (for bottom-up layouts):
casting ptrdiff_t to size_t produces ~2^64, causing memcpy to
attempt reading exabytes, resulting in an immediate crash.

The fix consists in using the size of the row buffer for the copy and
using the stride for pointer advancement only.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/e4f7ad4ea2a471776c81dda4846b7691925d9786 2026-01-09
CVE-2026-25646.patch Fix a heap buffer overflow in `png_set_quantize`
The color distance hash table stored the current palette indices, but
the color-pruning loop assumed the original indices. When colors were
eliminated and indices changed, the stored indices became stale. This
caused the loop bound `max_d` to grow past the 769-element hash array.

The fix consists in storing the original indices via `palette_to_index`
to match the pruning loop's expectations.		 Cosmin Truta <ctruta@gmail.com> yes debian upstream https://github.com/pnggroup/libpng/commit/01d03b8453eb30ade759cd45c707e5a1c7277d88 2026-02-06

All known versions for source package 'libpng1.6'

Links