SUSE-SU-2026:24205-1: moderate: Security update for libheif

SLE-SECURITY-UPDATES null at suse.de
Tue Oct 20 20:46:33 UTC 2026 

# Security update for libheif

Announcement ID: SUSE-SU-2026:24205-1  
Release Date: 2026-10-08T06:18:28Z  
Rating: moderate  
References:

  * bsc#1281829
  * bsc#1281948
  * bsc#1281949
  * bsc#1281950
  * bsc#1281951
  * bsc#1281952
  * bsc#1281953
  * bsc#1281954

  
Cross-References:

  * CVE-2020-6851
  * CVE-2026-84449

  
CVSS scores:

  * CVE-2020-6851 ( SUSE ):  7.8 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
  * CVE-2020-6851 ( NVD ):  7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
  * CVE-2026-84449 ( SUSE ):  5.1
    CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
  * CVE-2026-84449 ( SUSE ):  4.0 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
  * CVE-2026-84449 ( NVD ):  3.7 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

  
Affected Products:

  * SUSE Linux Enterprise Server 16.0
  * SUSE Linux Enterprise Server for SAP applications 16.0

  
  
An update that solves two vulnerabilities and has six fixes can now be
installed.

## Description:

This update for libheif fixes the following issues:

  * CVE-2026-84449: hOp_RGB24_32_to_YCbCr Memory Access Error / SEGV
    (bsc#1281829).
  * AV1/libaom path allows allocation before libheif rejects mismatched coded
    dimensions (bsc#1281953).
  * Caller-configured security limits not enforced for MINI-box parsing
    (bsc#1281952).
  * Heap out-of-bounds read in libheif alpha compositing via mismatched per-
    channel bit depths (bsc#1281951).
  * Heap-use-after-free and double free in
    ImageItem::encode_to_bitstream_and_boxes (bsc#1281949).
  * Incomplete OpenJPEG pre-decode security limits allow unsafe decode through
    the public API (bsc#1281954).
  * JPEG 2000 pclr zero-column allocation amplification bypasses
    max_total_memory (bsc#1281950).
  * Out-of-bounds heap read in unc_encoder_rgb_pixel_interleave (bsc#1281948).

Changes for libheif:

  * 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)

## Patch Instructions:

To install this SUSE update use the SUSE recommended installation methods like
YaST online_update or "zypper patch".  
Alternatively you can run the command listed for your product:

  * SUSE Linux Enterprise Server for SAP applications 16.0  
    zypper in -t patch SUSE-SLES-16.0-1865

  * SUSE Linux Enterprise Server 16.0  
    zypper in -t patch SUSE-SLES-16.0-1865

## Package List:

  * SUSE Linux Enterprise Server for SAP applications 16.0 (ppc64le x86_64)
    * libheif-debugsource-1.23.5-160000.1.1
    * libheif-aom-debuginfo-1.23.5-160000.1.1
    * libheif-openjpeg-1.23.5-160000.1.1
    * libheif1-1.23.5-160000.1.1
    * libheif-aom-1.23.5-160000.1.1
    * libheif-ffmpeg-debuginfo-1.23.5-160000.1.1
    * libheif-ffmpeg-1.23.5-160000.1.1
    * gdk-pixbuf-loader-libheif-1.23.5-160000.1.1
    * libheif-dav1d-debuginfo-1.23.5-160000.1.1
    * libheif1-debuginfo-1.23.5-160000.1.1
    * libheif-openjpeg-debuginfo-1.23.5-160000.1.1
    * libheif-dav1d-1.23.5-160000.1.1
    * libheif-jpeg-1.23.5-160000.1.1
    * libheif-rav1e-debuginfo-1.23.5-160000.1.1
    * libheif-jpeg-debuginfo-1.23.5-160000.1.1
    * libheif-rav1e-1.23.5-160000.1.1
    * gdk-pixbuf-loader-libheif-debuginfo-1.23.5-160000.1.1
  * SUSE Linux Enterprise Server for SAP applications 16.0 (x86_64)
    * libheif-svtenc-1.23.5-160000.1.1
    * libheif-svtenc-debuginfo-1.23.5-160000.1.1
  * SUSE Linux Enterprise Server 16.0 (aarch64 ppc64le s390x x86_64)
    * libheif-debugsource-1.23.5-160000.1.1
    * libheif-aom-debuginfo-1.23.5-160000.1.1
    * libheif-openjpeg-1.23.5-160000.1.1
    * libheif1-1.23.5-160000.1.1
    * libheif-aom-1.23.5-160000.1.1
    * libheif-ffmpeg-debuginfo-1.23.5-160000.1.1
    * libheif-ffmpeg-1.23.5-160000.1.1
    * gdk-pixbuf-loader-libheif-1.23.5-160000.1.1
    * libheif-dav1d-debuginfo-1.23.5-160000.1.1
    * libheif1-debuginfo-1.23.5-160000.1.1
    * libheif-openjpeg-debuginfo-1.23.5-160000.1.1
    * libheif-dav1d-1.23.5-160000.1.1
    * libheif-jpeg-1.23.5-160000.1.1
    * libheif-rav1e-debuginfo-1.23.5-160000.1.1
    * libheif-jpeg-debuginfo-1.23.5-160000.1.1
    * libheif-rav1e-1.23.5-160000.1.1
    * gdk-pixbuf-loader-libheif-debuginfo-1.23.5-160000.1.1
  * SUSE Linux Enterprise Server 16.0 (aarch64 x86_64)
    * libheif-svtenc-1.23.5-160000.1.1
    * libheif-svtenc-debuginfo-1.23.5-160000.1.1

## References:

  * https://www.suse.com/security/cve/CVE-2020-6851.html
  * https://www.suse.com/security/cve/CVE-2026-84449.html
  * https://bugzilla.suse.com/show_bug.cgi?id=1281829
  * https://bugzilla.suse.com/show_bug.cgi?id=1281948
  * https://bugzilla.suse.com/show_bug.cgi?id=1281949
  * https://bugzilla.suse.com/show_bug.cgi?id=1281950
  * https://bugzilla.suse.com/show_bug.cgi?id=1281951
  * https://bugzilla.suse.com/show_bug.cgi?id=1281952
  * https://bugzilla.suse.com/show_bug.cgi?id=1281953
  * https://bugzilla.suse.com/show_bug.cgi?id=1281954

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.suse.com/pipermail/sle-security-updates/attachments/20261020/29d1f5b8/attachment.htm>

More information about the sle-security-updates mailing list