Source: libheif Version: 1.21.2-4 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for libheif. Rationale for not making single bugreports: All issues should be fixed in the 1.22.0 version. Older versions have not been assessed for each individual version but so you are at least awaere of the batch of CVE assignments. CVE-2026-32738[0]: | libheif is a HEIF and AVIF file format decoder and encoder. In | versions 1.21.2 and below, a crafted 792-byte HEIF sequence file | with samples_per_chunk=0 in the stsc box causes an unsigned integer | underflow in the Chunk constructor (m_last_sample = 0 + 0 - 1 = | UINT32_MAX), mapping all samples to an empty chunk and resulting in | a denial of service. When any sample is accessed, the library reads | from index 0 of an empty std::vector, causing a guaranteed SEGV | (null-page read). The file parses successfully without producing an | error; the crash occurs on the first frame access. This issue has | been fixed in version 1.22.0. CVE-2026-32739[1]: | libheif is a HEIF and AVIF file format decoder and encoder. In | versions 1.21.2 and below, a crafted 800-byte HEIF sequence file | causes an infinite loop in Box_stts::get_sample_duration(), | consuming 100% CPU indefinitely with zero progress, leading to DoS. | The loop has no iteration limit or timeout and is triggered during | file open (parsing) - before any user interaction or image decoding. | The process stays alive (no crash, no error logged), making it | invisible to crash-based monitoring. This issue has been fixed in | version 1.22.0. CVE-2026-32740[2]: | libheif is a HEIF and AVIF file format decoder and encoder. Versions | 1.21.2 and prior contain a heap-buffer-overflow (write) | vulnerability in the grid tile compositing, allowing an attacker to | write 64 bytes of fully attacker-controlled data past the end of a | chroma plane heap allocation by crafting a HEIF/AVIF file with a 1×4 | grid of odd-height tiles. The overflow is triggered during normal | image decoding with default build configuration. The written bytes | are chroma (Cb/Cr) pixel values from the attacking tile, giving the | attacker full control over the overflow content. This issue has been | fixed in version 1.22.0. CVE-2026-32741[3]: | libheif is a HEIF and AVIF file format decoder and encoder. Versions | 1.21.2 and below contain a heap buffer overflow in | MaskImageCodec::decode_mask_image(). When decoding a HEIF file | containing a mask image (mski), the function copies the full iloc | extent data into a pixel buffer using memcpy(dst, data.data(), | data.size()). The copy length data.size() is determined by the iloc | extent in the file (attacker-controlled), while the destination | buffer is sized based on the declared image dimensions. Because no | upper-bound check exists on the data length, a crafted file whose | iloc extent exceeds the pixel buffer allocation overflows the heap. | The vulnerable single-memcpy branch is reached when the mskC | property specifies bits_per_pixel = 8 and the ispe property declares | an even width ≥ 64 (so that stride == width), with no changes to | default security limits or external codec plugins required. This | issue has been fixed in version 1.22.0. CVE-2026-32814[4]: | libheif is a HEIF and AVIF file format decoder and encoder. In | versions 1.21.2 and prior, when decoding a HEIF grid image with | strict_decoding=false (the default), a corrupted tile silently fails | to decode and the library returns heif_error_Ok with no indication | of failure, leading to an uninitialized heap memory information | leak. The canvas is allocated via create_clone_image_at_new_size() → | plane.alloc() → new (std::nothrow) uint8_t[allocation_size] which | does not zero the memory; only the alpha plane is explicitly | initialized via fill_plane(), so the Y, Cb, and Cr planes contain | whatever was previously at that heap address. The failed tile's | region of the canvas is never written. It retains uninitialized heap | data that is delivered to the caller as decoded pixel values (4,096 | bytes per Y/Cb/Cr plane = 12,288+ bytes total). Any application | using libheif to decode grid-based HEIF/AVIF files with default | settings is vulnerable: a crafted .heic or .avif file causes 4,096+ | bytes of heap memory to appear as pixel values in the decoded image, | and the calling application receives heif_error_Ok, so it has no | indication the output contains heap garbage. In server-side image | processing, an uploaded crafted HEIF decoded and re-encoded (e.g., | as PNG/JPEG for thumbnails, CDN, social media) can leak cross-user | data such as auth tokens, database results, and other users' image | data. This issue has been fixed in version 1.22.0. CVE-2026-32882[5]: | libheif is a HEIF and AVIF file format decoder and encoder. Versions | 1.21.2 and prior contain a heap buffer over-read in | HeifPixelImage::overlay() in libheif/pixelimage.cc. When compositing | an overlay image (iovl) whose child image has a different bit depth | for the alpha channel than for the color channels, the function | indexes into the alpha plane using the color channel stride | (in_stride) instead of the previously retrieved alpha_stride, | causing reads past the end of the alpha buffer (up to 3,123 bytes | for a 100×50 image with 10-bit color and 8-bit alpha). A crafted | HEIF file can exploit this to cause a denial of service (crash) or | potentially disclose adjacent heap memory through leaked bytes | embedded in the decoded output pixels. This issue has been fixed in | versionThis issue has been fixed in version 1.22.0. CVE-2026-41069[6]: | libheif is a HEIF and AVIF file format decoder and encoder. In | versions 1.21.2 and prior, a malformed HEIF sequence file can | trigger an out-of-bounds read in core sequence parsing logic, | causing DoS. A malformed file can have stco.entry_count == 0 | (creating no chunks) while still passing validation because | saio.entry_count == 0 matches, but with saiz.sample_count > 0 the | SampleAuxInfoReader constructor still enters its loop. This leads to | an out-of-bounds dereference on the empty chunks[0] in chunked mode. CVE-2026-41071[7]: | libheif is a HEIF and AVIF file format decoder and encoder. In | versions 1.21.2 and prior, a crafted HEIF sequence file where the | saiz box declares more samples than actually exist in the track's | chunk table causes a heap-buffer-overflow (out-of-bounds read) in | the SampleAuxInfoReader constructor. The SampleAuxInfoReader | constructor iterates over saiz->get_num_samples() samples but | doesn't validate that this count is consistent with the number of | chunks in the chunks vector. When saiz declares more samples than | the chunks cover, the loop increments current_chunk past | chunks.size(), causing an out-of-bounds read on the chunks vector. | The vulnerability is triggered during file parsing | (heif_context_read_from_file) without any additional user | interaction. Any application using libheif to open untrusted HEIF | files is affected. This issue has been fixed in version 1.22.0. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-32738 https://www.cve.org/CVERecord?id=CVE-2026-32738 [1] https://security-tracker.debian.org/tracker/CVE-2026-32739 https://www.cve.org/CVERecord?id=CVE-2026-32739 [2] https://security-tracker.debian.org/tracker/CVE-2026-32740 https://www.cve.org/CVERecord?id=CVE-2026-32740 [3] https://security-tracker.debian.org/tracker/CVE-2026-32741 https://www.cve.org/CVERecord?id=CVE-2026-32741 [4] https://security-tracker.debian.org/tracker/CVE-2026-32814 https://www.cve.org/CVERecord?id=CVE-2026-32814 [5] https://security-tracker.debian.org/tracker/CVE-2026-32882 https://www.cve.org/CVERecord?id=CVE-2026-32882 [6] https://security-tracker.debian.org/tracker/CVE-2026-41069 https://www.cve.org/CVERecord?id=CVE-2026-41069 [7] https://security-tracker.debian.org/tracker/CVE-2026-41071 https://www.cve.org/CVERecord?id=CVE-2026-41071 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
