Bundled libheif 1.20.1 / libde265 1.0.15: heap overflows decoding HEIC (fixed upstream)

[dkgkdfg65]

JarkViewer bundles libheif 1.20.1 and libde265 1.0.15 (via vcpkg libheif[hevc]). Both have heap out-of-bounds writes reachable when opening a crafted .heic/.heif (ImageDatabase::loadHeic -> heif_decode_image):

1. libheif < 1.22.0 -- decode_mask_image (mask_image.cc) on the stride==width path copies the full item payload into a width*height plane; the only size check is a lower bound, so an oversized mski item overflows the heap. ASan on 1.20.1: heap-buffer-overflow WRITE in mask_image.cc. Fixed upstream by commit 123694271a (CVE-2026-32741).

2. libde265 < 1.1.1 -- set_SliceHeaderIndex (image.h:740) writes past a MetaDataArray<CTB_info> allocation on a crafted HEVC (hvc1) primary item via read_coding_tree_unit. ASan on 1.0.15: heap-buffer-overflow WRITE. Fixed upstream in libde265 1.1.1 (CVE-2026-33165).

Both reproduce on standalone ASan builds of the bundled versions with small crafted HEIC inputs, and are clean on the fixed versions. Opening any HEIC dispatches to these bundled decoders, so a malicious image file alone triggers it.

Fix: bump bundled libheif to >= 1.22.0 and libde265 to >= 1.1.1 (e.g. update the vcpkg baseline).

[dkgkdfg65]

Small correction on the fix path -- I looked closer at how the libs are wired in. The project doesn't resolve libheif/libde265 through a vcpkg manifest at build time (VcpkgEnabled is false in the vcxproj); the repo only carries the headers (JarkViewer/include/libheif, .../libde265, pinned at 1.20.1 / 1.0.15), and the actual static libs ship separately in the static_lib release asset (the .lib files are gitignored).

So the vulnerable code lives in the prebuilt .lib, not in the tree -- editing the version headers alone wouldn't fix anything (and would desync the headers from the libs). The fix has to happen when you rebuild the release: re-run vcpkg install libheif[core,hevc]:x64-windows-static against a current vcpkg so it pulls libheif >= 1.22.0 (and libde265 >= 1.1.1), then refresh both the committed headers and the static_lib asset from the new installed/x64-windows-static tree. Might be worth pinning a minimum version in the README install step too. Thanks.