libheif is a HEIF and AVIF file format decoder and encoder. Prior to 1.23.2, crafted HEIF sequence timing and edit-list data can make Track::initsampletimingtable() compute a logical mnumoutputsamples value that exceeds the uint32t counters used by TrackVisual::decodenextimagesample() and Track::getnextsamplerawdata(). The resulting comparison can never reach the oversized output count, causing non-terminating decode or raw-sample loops and bypassing maxsequenceframes. The same sequence path repeatedly calls Boxstts::getsampleduration() and allocates Chunk::msampleranges and Track::mpresentationtimeline outside MemoryHandle accounting, allowing severe CPU and memory exhaustion from a small file. This issue is fixed in version 1.23.2.

On 8/19/25 03:35, Martin Storsjö wrote: On Fri, 15 Aug 2025, Demi Marie Obenour wrote: What is your recommendation to distro maintainers? My understanding is that the full codec is included in the flathub runtimes but am not sure. Not sure about what to recommend. From what has been shared, fdk-aac-free does indeed seem insecure and/or hard to maintain.

If someone has time to invest in it, it could be fixable by trying to recreate the transformation from fdk-aac to fdk-aac-free in the form of a small patchset that can be rebased, or a script, ripping out the unwanted parts. Unfortunately, going forward with newer versions of fdk-aac, there can be more new algorithms that also may need to be patched out (there was a pretty big dump of new stuff a number of years ago), so it probably needs to be re-audited wrt patents after major updates. Is it worthwhile for distros to even try to ship an unencumbered AAC decoder, or should they leave multimedia support to third-party platforms that can freely ship full codecs? With Flathub that is much more feasible than it used to be. -- Sincerely, Demi Marie Obenour (she/her/hers)