Script 'mail_helper' called by obssrc Hello community, here is the log from the commit of package libheif for openSUSE:Factory checked in at 2026-09-23 14:32:20 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/libheif (Old) and /work/SRC/openSUSE:Factory/.libheif.new.383539 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "libheif" Wed Sep 23 14:32:20 2026 rev:60 rq:1379534 version:1.23.5 Changes: -------- --- /work/SRC/openSUSE:Factory/libheif/libheif.changes 2026-09-18 22:03:26.857821064 +0200 +++ /work/SRC/openSUSE:Factory/.libheif.new.383539/libheif.changes 2026-09-23 14:32:46.699888332 +0200 @@ -1,0 +2,80 @@ +Mon Sep 21 19:05:50 UTC 2026 - Dirk Müller <[email protected]> + +- update to 1.23.5: + * (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) + * (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) + * (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) + * (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) + * (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) + + +------------------------------------------------------------------- Old: ---- libheif-1.23.4.tar.gz New: ---- libheif-1.23.5.tar.gz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ libheif.spec ++++++ --- /var/tmp/diff_new_pack.bgywn9/_old 2026-09-23 14:32:48.039944353 +0200 +++ /var/tmp/diff_new_pack.bgywn9/_new 2026-09-23 14:32:48.041944437 +0200 @@ -47,7 +47,7 @@ %bcond_with heif_view Name: libheif%{?psuffix} -Version: 1.23.4 +Version: 1.23.5 Release: 0 Summary: HEIF/AVIF file format decoder and encoder License: LGPL-3.0-only AND MIT ++++++ libheif-1.23.4.tar.gz -> libheif-1.23.5.tar.gz ++++++ ++++ 10750 lines of diff (skipped)
