This fixes a regression introduced during the merge of tag 'v1.6.57'
into branch 'libpng18' and further into branch 'develop'. That merge
brought in `pnggetset_LDADD` with the libpng 1.x library name
`libpng@PNGLIB_MAJOR@@PNGLIB_MINOR@.la`, which incorrectly resolved
to `libpng20.la` on 'develop'. The correct library name on this branch
is `libpng2.la`.
Use the "Visual Studio 18 2026" CMake generator in all Windows jobs
of the GitHub Actions workflow. After the "windows-11-arm" label was
repointed to a new image that contains Visual Studio 2026 only, the
previous version-exact generator on Windows ARM64 no longer matched
any installed instance.
Use the "Visual Studio 18 2026" CMake generator in all Windows jobs
of the GitHub Actions workflow. After the "windows-11-arm" label was
repointed to a new image that contains Visual Studio 2026 only, the
previous version-exact generator on Windows ARM64 no longer matched
any installed instance.
This is a cherry-pick of commit 5e9b33f631
from branch 'libpng18'.
The zstream buffer pointers and counters are all cleared on acquisition
in `png_inflate_claim`, but only `next_in` and `avail_in` were cleared
on release in `png_read_finish_IDAT`, and none were cleared on release
in the chunk decompression paths.
If `png_read_end` is called before row reading starts, the IDAT stream
is never claimed. Previously, a leftover non-zero `avail_in` caused the
refill in `png_read_IDAT_data` to be skipped, and inflation continued
through a stale `next_in` into an input buffer that may since have been
deallocated.
Introduce the function `png_inflate_detach_buffers` to clear the
pointers and the counters of zstream input and output buffers on both
acquisition and release. Although clearing `next_out` and `avail_out`
is not currently necessary at any call site, it makes release mirror
acquisition at a negligible cost paid once for each zlib stream.
Reported-by: Ze Sheng <OwenSanzas@users.noreply.github.com>
Reported-by: JasonHonKL <JasonHonKL@users.noreply.github.com>
The zstream buffer pointers and counters are all cleared on acquisition
in `png_inflate_claim`, but only `next_in` and `avail_in` were cleared
on release in `png_read_finish_IDAT`, and none were cleared on release
in the chunk decompression paths.
If `png_read_end` is called before row reading starts, the IDAT stream
is never claimed. Previously, a leftover non-zero `avail_in` caused the
refill in `png_read_IDAT_data` to be skipped, and inflation continued
through a stale `next_in` into an input buffer that may since have been
deallocated.
Introduce the function `png_inflate_detach_buffers` to clear the
pointers and the counters of zstream input and output buffers on both
acquisition and release. Although clearing `next_out` and `avail_out`
is not currently necessary at any call site, it makes release mirror
acquisition at a negligible cost paid once for each zlib stream.
This is a cherry-pick of commit 6c7783b151
from branch 'libpng18'.
Reported-by: Ze Sheng <OwenSanzas@users.noreply.github.com>
Reported-by: JasonHonKL <JasonHonKL@users.noreply.github.com>
All necessary autotools packages are now preinstalled in the GitHub
Actions Ubuntu runner images.
This is a cherry-pick of commit 964b413594
from branch 'libpng18'.
Without an explicit declaration, the workflow token carries write
access to the repository on push events, although our project only
needs read access. Restrict the grant to limit what a compromised
action can reach.
Also harden the dependency step: replace context expressions such as
`${{ github.ref }}` with environment variables to prevent expansion
as shell code.
Resolves: https://github.com/pnggroup/libpng/pull/879
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Without an explicit declaration, the workflow token carries write
access to the repository on push events, although our project only
needs read access. Restrict the grant to limit what a compromised
action can reach.
Also harden the dependency step: replace context expressions such as
`${{ github.ref }}` with environment variables to prevent expansion
as shell code.
This is a cherry-pick of commit ef395b942d
from branch 'libpng18'.
Resolves: https://github.com/pnggroup/libpng/pull/879
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The hIST chunk was incorrectly positioned in the code. According to the
W3C specification, the hIST chunk must appear before the first IDAT
chunk and after PLTE (if present). This commit corrects the chunk
positioning to comply with the specification.
This is a cherry-pick of commit 9ecda6eaf5
from branch 'libpng18'.
Signed-off-by: Chris Lilley <chris@w3.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This is a cherry-pick of commit c2831cb0e6
from branch 'libpng18'.
Signed-off-by: Chris Lilley <chris@w3.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Clear the pointers inside `png_struct` after `png_free`, following the
existing idiom in `png_read_buffer`, to ensure that a subsequent free
will be a no-op.
Several read-side functions free a `png_struct` member and allocate
a replacement without clearing the pointer in between. When that
allocation fails, `png_malloc` calls `png_error`, which longjmps out
before the assignment, leaving the member pointing at freed memory.
The application's cleanup path (`png_destroy_read_struct`, then
`png_read_destroy`) then frees it a second time.
The same defect occurs at five members across four functions:
- `big_row_buf` and `big_prev_row` in `png_read_start_row`;
- `palette` in `png_set_PLTE`;
- `trans_alpha` in `png_set_tRNS`;
- `quantize_index` in `png_set_quantize`.
This is robustness hardening, not a fix for untrusted input. Arming
the double-free needs a prior successful pass through the same site,
and PNG content alone cannot deliver one: duplicate PLTE and tRNS
chunks are rejected before their setters run, and within a single
decode the row dimensions never grow, so the row-buffer reallocation
guard cannot re-fire.
The trigger is an application that causes a setter to run twice on one
`png_struct` or reuses the struct across decodes, and then meets an
allocation failure.
This is a cherry-pick of commit a22696be0a
from branch 'libpng18'.
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Anthony Hurtado <amhurtado@pm.me>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Clear the pointers inside `png_struct` after `png_free`, following the
existing idiom in `png_read_buffer`, to ensure that a subsequent free
will be a no-op.
Several read-side functions free a `png_struct` member and allocate
a replacement without clearing the pointer in between. When that
allocation fails, `png_malloc` calls `png_error`, which longjmps out
before the assignment, leaving the member pointing at freed memory.
The application's cleanup path (`png_destroy_read_struct`, then
`png_read_destroy`) then frees it a second time.
The same defect occurs at five members across four functions:
- `big_row_buf` and `big_prev_row` in `png_read_start_row`;
- `palette` in `png_set_PLTE`;
- `trans_alpha` in `png_set_tRNS`;
- `quantize_index` in `png_set_quantize`.
This is robustness hardening, not a fix for untrusted input. Arming
the double-free needs a prior successful pass through the same site,
and PNG content alone cannot deliver one: duplicate PLTE and tRNS
chunks are rejected before their setters run, and, although APNG
re-runs `png_read_start_row` on every frame, fcTL validation caps
each frame to the first frame's dimensions, so the row-buffer
reallocation guard cannot re-fire within one decode.
The trigger is an application that causes a setter to run twice on one
`png_struct` or reuses the struct across decodes, and then meets an
allocation failure.
Co-authored-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Anthony Hurtado <amhurtado@pm.me>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The "windows-latest" alias was repointed to a Windows Server 2025 image
that ships Visual Studio 2026 only, which prevented the version-exact
generator "Visual Studio 17 2022" from matching any installed instance.
This is a cherry-pick of commit dd5d363ae1
from branch 'libpng18'.
The "windows-latest" alias was repointed to a Windows Server 2025 image
that ships Visual Studio 2026 only, which prevented the version-exact
generator "Visual Studio 17 2022" from matching any installed instance.
Also change the copyright notice format in source files:
- Old format: "Copyright (c) <Author> <Year>-<Year>"
- New format: "Copyright (C) <Author> <Year>"
The new format is meant to reduce the diff output and to alleviate the
maintenance burden; the use of lowercase "(c)" vs. uppercase "(C)" is
meant to distinguish between the old format and the new format.
This is a cherry-pick of commit 28cb31ffa4
from branch 'libpng18'.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Also change the copyright notice format in source files:
- Old format: "Copyright (c) <Author> <Year>-<Year>"
- New format: "Copyright (C) <Author> <Year>"
The new format is meant to reduce the diff output and to alleviate the
maintenance burden; the use of lowercase "(c)" vs. uppercase "(C)" is
meant to distinguish between the old format and the new format.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
The palette sync in `png_read_transform_info` was guarded by
`if (transformations != 0)`, but the palette-modifying transforms clear
their own bits before this function gets to run. When one of these was
the sole transform, the guard was false and the sync was skipped, which
caused `png_get_PLTE` to return stale palette data.
Drop this guard.
This was a regression from commit c1b0318b39 (version 1.6.56).
Reported-by: ralfjunker <ralfjunker@users.noreply.github.com>
Resolves: https://github.com/pnggroup/libpng/issues/848
Restructure the trailing-fdAT path in the APNG push reader to check
`PNG_HAVE_fcTL` before calling `png_ensure_sequence_number`, in order
to ensure that an early return from insufficient buffer data cannot
sit between the sequence read and the body consumption.
Three inter-frame discard paths in `png_push_read_chunk` used to clear
the chunk-header flag without first consuming the chunk body and the
CRC field. On a subsequent call to `png_process_data`, the unconsumed
chunk bytes were reinterpreted as a fresh chunk header, which allowed
attacker-controlled data inside an ignored chunk to be smuggled into
the frame-data path.
Reported-by: 신승민 <guncraft2000@naver.com>
