CVS commit: pkgsrc/graphics/libheif

["Ryo ONODERA" <ryoon%netbsd.org@localhost>]

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.61 pkgsrc/graphics/libheif/Makefile
cvs rdiff -u -r1.52 -r1.53 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.61
--- pkgsrc/graphics/libheif/Makefile:1.60       Sun Sep 13 10:43:15 2026
+++ pkgsrc/graphics/libheif/Makefile    Sat Sep 26 08:39:28 2026
@@ -1,6 +1,6 @@
-# $NetBSD: Makefile,v 1.60 2026/09/13 10:43:15 wiz Exp $
+# $NetBSD: Makefile,v 1.61 2026/09/26 08:39:28 ryoon 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.53
--- pkgsrc/graphics/libheif/distinfo:1.52       Sun Sep 13 10:43:15 2026
+++ pkgsrc/graphics/libheif/distinfo    Sat Sep 26 08:39:28 2026
@@ -1,6 +1,6 @@
-$NetBSD: distinfo,v 1.52 2026/09/13 10:43:15 wiz Exp $
+$NetBSD: distinfo,v 1.53 2026/09/26 08:39:28 ryoon 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