pkgsrc-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
CVS commit: [pkgsrc-2026Q3] pkgsrc/graphics/libheif
Module Name: pkgsrc
Committed By: maya
Date: Tue Oct 20 23:32:49 UTC 2026
Modified Files:
pkgsrc/graphics/libheif [pkgsrc-2026Q3]: Makefile distinfo
Log Message:
Pullup ticket #7281 - requested by taca
graphics/libheif: Security fix
Revisions pulled up:
- graphics/libheif/Makefile 1.61
- graphics/libheif/distinfo 1.53
---
Module Name: pkgsrc
Committed By: ryoon
Date: Sat Sep 26 08:39:28 UTC 2026
Modified Files:
pkgsrc/graphics/libheif: Makefile distinfo
Log Message:
graphics/libheif: Update to 1.23.5
Changelog:
v1.23.5 is a security and bugfix release. It is ABI- and API-compatible
with v1.23.4 and is a drop-in replacement.
One of the fixed issues is rated high, so all users are advised to
upgrade.
## Security fixes
(CVE numbers will be added when assigned.)
* CVE-2026-XXXXX (GHSA-v8qw-hwjv-44hw) Memory exhaustion through
a mismatch between the container and the bitstream image size.
A crafted image can declare a small size in its ispe property
while the bitstream declares a much larger coded frame. The
container-level checks used the ispe size, so the oversized
bitstream reached the decoder, which allocated a frame buffer
for the in-band size before libheif rejected the mismatch. The
advisory demonstrated this for AV1 with the libaom backend (a
351-byte AVIF declaring 64x64 but coding up to 27648x27648,
allocating hundreds of MB to more than 10 GB), but the same class
affects every codec whose real frame size lives in the bitstream.
The coded size is now checked against max_image_size_pixels in
the codec-independent decode path, before any bytes reach a
decoder plugin: all AV1 sequence headers, all HEVC/AVC/VVC SPS
NAL units (including those carried in the item data, not only
the ones in the configuration record), the JPEG SOF marker and
the JPEG 2000 SIZ reference grid are scanned for the largest
coded size. (high)
* CVE-2026-XXXXX (GHSA-qwpf-5wf7-r996) Heap use-after-free and
double free when encoding an image that carries a TAI timestamp,
including transcoding a file with an itai property. ImageDescription
shallow-copied its raw heif_tai_timestamp_packet pointer, and a
temporary in ImageItem::encode_to_bitstream_and_boxes() freed
the packet while the item and the source image still held it.
The timestamp is now stored by value. (medium)
* CVE-2026-XXXXX (GHSA-9c75-9g8r-4728) Memory amplification
through a JPEG 2000 pclr box declaring zero palette columns. The
entry-count bound was skipped for zero columns, so an 11-byte
box allocated 65,535 empty palette entries, and nested j2kH
containers could repeat this within the child and nesting limits:
a 3 KB file reached about 330 MB RSS, none of it charged to
max_total_memory. Zero columns are rejected (ISO/IEC 15444-1
requires 1 to 255), the byte bound is unconditional, and the
palette storage is charged to the memory limits. (medium)
* CVE-2026-XXXXX (GHSA-r7gr-2xm2-23wf) Heap out-of-bounds read
in alpha compositing for uncompressed (unci) images whose colour
planes have different bit depths. Op_flatten_alpha_plane read
every plane through the sample type of the first colour plane,
so an 8-bit blue plane next to 16-bit red and green planes was
read with a halved stride past its end, and the bytes ended up
in the composited output. ColorState now tracks one bit depth
per plane, and the operator declines mixed sample widths at
planning time. (medium)
* CVE-2026-XXXXX (GHSA-q492-cfcm-895h) The OpenJPEG decoder
plugin's pre-decode size check bounded the JPEG 2000 window span
(x1-x0)*(y1-y0) but not the absolute reference-grid coordinates,
so a codestream with a 17-pixel window on a grid near the 32-bit
boundary reached opj_decode(). Against OpenJPEG 2.3.1 this produced
a heap-buffer-overflow write inside OpenJPEG (the class of
CVE-2020-6851); OpenJPEG 2.5.4 rejects the input. The reference-grid
area is now bounded as well. (low)
* (GHSA-qfj5-c4pq-q998) Heap out-of-bounds read in the uncompressed
encoder when an application attached a separate alpha plane to
an image with an interleaved chroma format. The interleaved
encoders took their component list from the chroma format (three
entries) but decided whether to write alpha from the presence of
an alpha plane, and indexed the list at [3]. heif_image_add_plane()
now rejects a separate alpha plane on interleaved images, and
the encoders derive both decisions from the chroma format. Only
reachable through the public API; decoding never produces such
an image. (low)
* (GHSA-7pwf-qh74-p35w) The caller's heif_security_limits were
not applied when parsing a mini box (the MIAF minimized image
format) or the av1C/hvcC blob embedded in it; the built-in defaults
were used instead. An application that tightened the limits got
no enforcement of its max_memory_block_size or max_total_memory
on such files. The allocations are bounded by the bytes present
in the box, so this could not amplify memory use. (low)
Thanks to @homm, @jitxie (Yunding Lab, Tencent Security), @peter-hendy,
@joelczk, @adamyordan, @k3mlol, @bruhdev1290 and @hyunjungdoh for
reporting these issues, and to @SomnathDas, @sil3ntwizard and
@iceray00 for the reports behind the API-contract and UBSan items
under Hardening.
## Hardening
* Colour conversion tracks one bit depth per plane instead of
one image-wide value, and every operator declares the sample
width and the per-plane depths it can read, so images with mixed
plane depths (which unci allows) are declined at planning time
instead of being caught, or not, by runtime checks. The blanket
check that refused every mixed-depth YCbCr conversion
(GHSA-w7mc-p8jc-p853) is replaced by per-operator constraints
* The colour-conversion and encoder entry points verify the plane
layout: the planes that an image's colorspace and chroma format
imply must be present exactly once, at the implied sizes. Missing,
duplicate or foreign planes previously failed deep inside an
operator, passed through as a no-op, or hit an assert() in the
x265 plugin that release builds compile out
* heif_image_add_plane() rejects a Cb or Cr plane whose size does
not match the chroma subsampling of the image. An oversized plane
built this way fooled the row fill in
heif_image_extend_to_size_fill_with_zero() into a 4 GB out-of-bounds
write (GHSA-j2rv-58fh-w8pw), an undersized one caused out-of-bounds
reads in the RGB conversion (#1796). Only reachable by an
application constructing an inconsistent image through the public
API
* heif_image_extend_to_size_fill_with_zero() rejects a target
smaller than the current image with a usage error instead of
underflowing the fill length and writing past the plane
(GHSA-hqc2-cx5m-g6ff, only reachable by out-of-contract API use)
* memcpy() is never called with a NULL pointer, even for zero-length
copies (empty box payloads, zero-length iloc extents, empty ICC
profiles or masks). This is undefined behaviour in C17 and C++
and was reported by UBSan (GHSA-2764-mqj2-c458, GHSA-x8qp-vqp7-mm4r)
* JPEG 2000 pclr: the palette precision field is read and written
as the specification defines it (the low 7 bits hold the precision
minus one), and the entry count is returned as the 16-bit value
it is
## Bug fixes
* Overlay (iovl) images with negative 16-bit offsets lost the
affected layer: the sign extension was wrong for the 2-byte offset
form, so the layer was placed far outside the canvas (since
v1.19.2, conformance files C019 and C021)
* Overlay layers with a negative offset were clipped wrongly: a
layer whose negative offset was at least half its size was not
drawn at all, smaller negative offsets drew a truncated part,
and the alpha path wrote to the wrong column (since v1.20.0)
* An item may be referenced repeatedly within one iref entry. An
overlay that places the same input image at two positions references
it twice in its dimg entry, and such files (conformance file
C021) were rejected since v1.17.0; heif_context_add_overlay_image()
could not write them either. The same applies to a repeated track
ID within one tref reference type box
* Visual sequences: each decoded frame received the duration of
the next pushed sample instead of its own, so a variable frame
rate sequence with the durations {100, 250, 400} decoded as {250,
400, 100} (#1914)
* Sequence encoding with x265 aborted on the header-only first
drain in builds with the libstdc++ assertions enabled (Fedora's
default), because the pending output was moved out of a std::optional
instead of being extracted (#1907)
* kvazaar: monochrome and alpha auxiliary images crashed with
kvazaar git master, which keeps the chroma format in new config
fields that only the input-format parser updates. The input format
is now set through config_parse(), and chroma formats a kvazaar
build does not support return an error (#1915)
* Uncompressed Bayer (filter array) images could not be decoded
to a different bit depth: 8-bit to 16-bit interleaved RGB and
12-bit to 8-bit RGB failed with "Invalid bit depth", and a native
decode of a 12-bit Bayer image with convert_hdr_to_8bit returned
an image without planes
* Compositing the alpha of a monochrome image failed with
"unsupported color conversion" for monochrome and RGB targets;
luma-only images are now composited directly on their Y plane
* Decoding uncompressed images whose colour planes have different
depths to 8 bits depended on the order of the planes (RGB 8/8/16
was refused while 16/8/8 worked), and mixed-depth YCbCr images
(16/16/8) could not be decoded to 8-bit RGB at all
* FFmpeg decoder plugin: fixed a link failure with MSVC when
built as a dynamic plugin (#1854)
## Behavior changes
* The coded image size in the bitstream is checked against
max_image_size_pixels before decoding, for all codecs. Files
whose bitstream declares a frame larger than the limit are rejected
even when their ispe property is small
* heif_image_add_plane() rejects a separate alpha plane on an
image with an interleaved chroma format, and a Cb/Cr plane with
a size that does not match the chroma subsampling
* heif_image_extend_to_size_fill_with_zero() returns a usage
error for a target smaller than the current image
* Encoding an image whose planes do not match its colorspace and
chroma format returns a usage error; converting such an image
returns Unsupported_image_type
* Repeated references within one iref entry or one tref reference
type box are accepted
* JPEG 2000 pclr boxes with zero columns are rejected
To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.60.2.1 pkgsrc/graphics/libheif/Makefile
cvs rdiff -u -r1.52 -r1.52.2.1 pkgsrc/graphics/libheif/distinfo
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Modified files:
Index: pkgsrc/graphics/libheif/Makefile
diff -u pkgsrc/graphics/libheif/Makefile:1.60 pkgsrc/graphics/libheif/Makefile:1.60.2.1
--- pkgsrc/graphics/libheif/Makefile:1.60 Sun Sep 13 10:43:15 2026
+++ pkgsrc/graphics/libheif/Makefile Tue Oct 20 23:32:49 2026
@@ -1,6 +1,6 @@
-# $NetBSD: Makefile,v 1.60 2026/09/13 10:43:15 wiz Exp $
+# $NetBSD: Makefile,v 1.60.2.1 2026/10/20 23:32:49 maya Exp $
-DISTNAME= libheif-1.23.4
+DISTNAME= libheif-1.23.5
CATEGORIES= graphics
MASTER_SITES= ${MASTER_SITE_GITHUB:=strukturag/}
GITHUB_RELEASE= v${PKGVERSION_NOREV}
Index: pkgsrc/graphics/libheif/distinfo
diff -u pkgsrc/graphics/libheif/distinfo:1.52 pkgsrc/graphics/libheif/distinfo:1.52.2.1
--- pkgsrc/graphics/libheif/distinfo:1.52 Sun Sep 13 10:43:15 2026
+++ pkgsrc/graphics/libheif/distinfo Tue Oct 20 23:32:49 2026
@@ -1,6 +1,6 @@
-$NetBSD: distinfo,v 1.52 2026/09/13 10:43:15 wiz Exp $
+$NetBSD: distinfo,v 1.52.2.1 2026/10/20 23:32:49 maya Exp $
-BLAKE2s (libheif-1.23.4.tar.gz) = 267399327694d24235ae8131c357672eda192a20fe9537e82d81de6e9df71606
-SHA512 (libheif-1.23.4.tar.gz) = eef0fa12c0b3aed3bba60daeb3ea29d1e19b7b468b88ec09f86f4ccb87b8147a7b07ceb3cf63d75b4bce8cbf8c34c1c015e30c938d7b54a1a79ee07bb8cb4ead
-Size (libheif-1.23.4.tar.gz) = 2217221 bytes
+BLAKE2s (libheif-1.23.5.tar.gz) = 795f3cc309d69bdd5ab1ee93c9274f5de5598767ab0a9fc3915c279ead38ff53
+SHA512 (libheif-1.23.5.tar.gz) = 481f94d7b1a88edfcaa8218c3f07df8ed17609a7fcb79a48f42bddcc7dfb7412f4d68299808300e0c81d4d171aec9b3281922adc39bb49d94fd5b73ffcb2eb1f
+Size (libheif-1.23.5.tar.gz) = 2276803 bytes
SHA1 (patch-heifio_CMakeLists.txt) = dda4522707589342898c29bba189557895d75178
Home |
Main Index |
Thread Index |
Old Index