[pull] libpng16 from pnggroup:libpng16 #70
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
`PNG_LIBPNG_VER_BUILD` should be zero for public releases and non-zero for development versions. The ci_verify_version.sh script should check this requirement as such.
Work around a limitation in the `shellcheck source` directive, which does not recognize quotes in shellcheck versions older than 0.9. Also extend the checks for YAML files over the entire source tree, in preparation for the introduction of the GitHub Actions config file.
By definition, `sizeof(png_byte)` is 1. Remove all the occurences of `sizeof(png_byte)` from the code, and fix a related typo in the libpng manual. Also update the main .editorconfig file to reflect the fixing expected by a FIXME note.
Introduce the environment option CI_FORCE: * ci_verify_configure.sh is known to fail if an existing build configuration is found in the top-level directory. Setting CI_FORCE=1 will run `make distclean` before verification. * ci_verify_makefiles.sh cannot be reliably executed if random object files are found in the top-level directory. Setting CI_FORCE=1 will run `rm *.o *.obj` before verification. * ci_verify_cmake.sh is not known at this time to fail for similar reasons; but if it does, we will use CI_FORCE to trigger any necessary pre-build cleanup.
The variable `CI_LINT_COUNTER` was incremented inside subshells, but remained unchanged in the main shell process. The errors detected by the internal linters remained unreported by the main script. (Oopsie!) Besides fixing this defect, considering that only a pass/fail status is needed, we are replacing `CI_LINT_COUNTER` with `CI_LINT_STATUS`.
This fixes commit dddaf0c. The way to reliably `find` executable files is different on BSD, Mac and Linux, unfortunately.
This fixes commit 4edbb4d. During the move of CMake scripts to the scripts/cmake/ subdirectory, some of the workflows have been broken. Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Update the PNG_TOOLS option: set it to OFF by default when the target is an embedded system, yet still allow it to be overridden. Update the PNG_FRAMEWORK option: force it back to OFF and print a warning if the option was ON but the target is not an Apple system.
Add nawk to the list of AWK-processing programs that are known to work, and show the search result in the CMake log.
Declare AWK explicitly via the AC_ARG_VAR directive, in order to make it "precious", and to include it in the list of influential variables at the end of the configure help text. Rephrase a few comments and config traces. Finally, regenerate the configure script.
In the configure script, checking whether the LoongArch LSX intrinsics are supported by the compiler was done unconditionally, regardless of the targetted host platform. Compared to how we support the other SIMD platforms and compilers, this is rather unconventional. We are placing this check under the guard of its own platform, for the time being. A full solution, in line with the rest of the configure.ac patterns concering SIMD optimizations, is TODO. We also do an overall cleanup in the SIMD section of configure.ac, and, finally, we regenerate the configure script.
Modern compilers can disable the warnings that originate from system headers. This change allows them to do so with the libpng headers. Signed-off-by: Cosmin Truta <ctruta@gmail.com>
We used this experimental project in the development of the PNG-EXIF
("eXIf") specification, back in 2017. The project evolved together
with the draft specification, which was finalized on 2017-Jun-15 and
approved by the PNG Group on 2017-Jul-13.
The EXIF specification, outside of the scope of PNG and libpng, is
quite complex. The libpng implementation cannot grow too much beyond
performing basic integrity checks on top of serialization. In order
to create and manipulate PNG-EXIF image files, the use of external
libraries and tools such as ExifTool is necessary.
Now, with the addition of contrib/pngexif to the libpng repository,
offline tasks like metadata inspection and linting can be performed
without importing external dependencies.
The release tags are redundant in the CI process. It is the main branch that is always verified.
This fixes the bug #505 "libpng does not support PAC/BTI on aarch64 targets" which arises because the build mechanisms (both cmake and configure) assemble arm/filter_neon.S even though it ends up completely empty. The empty file effectively poisons the so that the PAC/BTI support gets disabled. The fix is minimal; it simply removes arm/filter_neon.S from the list of sources included in the 64-bit ARM builds build. Note that this was already done in cmake for MSVC - it's not clear whether this change was a partial fix for the same issue. This version of the fix ONLY affects aarch64 (arm64) builds; 32-bit ARM systems can still invoke the assembler if required and, indeed, there should be no change whatsover to those builds. The assembler code could not be used on 64-bit systems in any case so in practice there is no material change to 64-bit builds either. TESTING: pull the changes then type "autoreconf" if using configure (not required for cmake). TESTS: cmake has not been tested because cross-builds with cmake currently fail to find the zlib installation from the cmake system root path. The following has been tested with configure cross builds: armv7-linux-gnueabi [no neon support] armv7a-linux-gnueabi [no neon support] armv7a-hardfloat-linux-gnueabi [neon support not enabled] armv7a-hardfloat-linux-gnueabi -mfpu=neon [uses intrinics] armv7a-hardfloat-linux-gnueabi -mfpu=neon -DPNG_ARM_NEON_IMPLEMENTATION=2 [uses assembler] aarch64-linux-gnu [uses intrinsics] aarch64-linux-gnu -DPNG_ARM_NEON_OPT=0 [neon support disabled] Signed-off-by: John Bowler <jbowler@acm.org>
This file contains hand-coded assembler implementations of the filter functions for 32-bit Arm platforms. These are only used when the compiler doesn't support neon intrinsics (added to GCC 4.3 in 2008) or is exactly GCC 4.5.4 (released 2012), both of which are sufficiently unlikely to be true that it's fair to say the assembler is no longer used. This commit deletes filter_neon.S and removes the now obsolete preprocessor logic in pngpriv.h. Signed-off-by: Bill Roberts <bill.roberts@arm.com> Signed-off-by: Cosmin Truta <ctruta@gmail.com>
In the previous commit 9e53875 we removed the obsolete assembler implementation `filter_neon.S`. In this commit we add a stand-in for the original file, restoring the original source tree structure, for the benefit of continuing hassle-free libpng source upgrades in the 1.6.x line.
Initialize the arch-specific MSYSTEM environment variable, to ensure that msys2 bash picks up and executes /etc/profile correctly. Install and use the host-specific cmake and ninja, to ensure that msys2 cmake picks up the host-specific zlib build correctly.
Because of a missing "amd64" string (in lowercase) in a regex match, the CMake build was unable to pick up the PNG_HARDWARE_OPTIMIZATIONS flag on FreeBSD/amd64 (and possibly other amd64 systems as well). Rename the target arch variable from TARGET_ARCH to a more idiomatic PNG_TARGET_ARCHITECTURE, and set it to an always-lowercase string. The follow-on checks are now simpler and easier to get right.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Following up on commit a05a48b.
Use the correct RVV intrinsic, i.e., `__riscv_vaaddu_vv_u8m1` instead of `__riscv_vaaddu_wx_u8m1`. Reviewed-by: Cosmin Truta <ctruta@gmail.com> Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Also reformat the attribution comment in riscv/filter_rvv_intrinsics.c
Remove dead code left over from earlier iterations: - `abs_diff`, `abs_sum`, `prefix_sum`: unused helper functions; - `MIN_CHUNK_LEN`, `MAX_CHUNK_LEN`: macros used by `prefix_sum`.
Reviewed-by: Cosmin Truta <ctruta@gmail.com> Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Reported-by: Andrew Tribick <ajtribick@googlemail.com> Reviewed-by: Cosmin Truta <ctruta@gmail.com> Signed-off-by: Cosmin Truta <ctruta@gmail.com>
A benign type error introduced in libpng-1.0.9beta1 (Nov 2000) went unnoticed in reviews and testing for nearly 25 years. The type `voidp` (from zconf.h via zlib.h) is a plain "void pointer". By contrast, `png_voidp` (from pngconf.h via png.h) was defined as a "void FAR pointer" on legacy i8086 memory models (MSDOS, OS/2 2.x, Win16), and as a plain "void pointer" elsewhere. The support for FAR pointers in mixed-memory models was removed in libpng-1.6.0, which inadvertently "fixed" the underlying error. However, all libpng versions from 1.0.9 to 1.5.30 (Nov 2000–Sep 2017) remained broken on these models; and yet, nobody noticed. This typo illustrates how long we've been carrying pointer abstraction baggage without any confirmed benefit. This is a cherry-pick of commit 0ff3849 from branch 'libpng18'. Reviewed-by: Chris Blume <ProgramMax@gmail.com> Reviewed-by: Tobias Stoeckmann <tobias@stoeckmann.org> Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This is a cherry-pick of commit caa0c73 from branch 'libpng18'.
Fix a regression from commit 218612d. 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. Reported-by: Petr Simecek <simecek@users.noreply.github.com> Analyzed-by: Stanislav Fort Analyzed-by: Pavel Kohout Co-authored-by: Petr Simecek <simecek@users.noreply.github.com> Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Following up on commit e4f7ad4: The original naming of variables and fields in pngread.c was rather inconsistent and confusing. Apply the following sequence of renames: - Rename the image read control struct field `row_bytes` to `row_step` in order to clarify that this represents the signed stride between rows (which may include padding or be negative for bottom-up layouts), not the actual byte count of row data. - Standardize all local variable names: replace `step_row` and `row_bytes` with `row_step` throughout. Remove unnecessary casts to unsigned integer type in the direct read paths, preserving the signed `ptrdiff_t` type for correct stride semantics. - Rename the local variable `copy_bytes` to `row_bytes` in order to emphasize the semantic distinction between the row's byte count (used for memcpy length) and the row step (used for pointer advancement). Also add clarifying comments around the security-critical memcpy operation to document why row bytes and row step must be kept distinct.
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.
Following up on commit e4f7ad4: After we renamed variables and fields in pngread.c for better clarity, we are doing the same in pngwrite.c. Apply the following name changes: - Rename the image write control struct field `row_bytes` to `row_step` in order to clarify that this represents the signed stride between rows (which may include padding or be negative for bottom-up layouts), not the actual byte count of row data. - Standardize the local variable names to follow the new names in the image write control struct: replace `row_bytes` with `row_step`. Also following up on commit e4f7ad4: fix a typo inside a comment in pngread.c.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
From #764 Signed-off-by: Cosmin Truta <ctruta@gmail.com>
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. Reported-by: Joshua Inscoe <pwnalone@users.noreply.github.com> Co-authored-by: Joshua Inscoe <pwnalone@users.noreply.github.com> Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )