OpenEXR, sinema endüstrisinde yaygın olarak kullanılan EXR görüntü formatının referans uygulaması ve spesifikasyonudur. 3.4.0'dan 3.4.11'e kadar olan sürümlerde, OpenEXRCore'daki HTJ2K (Yüksek Verimli JPEG 2000) kod çözücüsü ht_undo_impl(), yığın arabellek taşması OKUMA'ya karşı savunmasızdır. Ht_undo_imp işlevi, yineleme sayısı olarak EXR kanalının bildirilen genişliğini kullanarak kodu çözülmüş pikselleri satır başına OpenJPH arabelleğinden kopyalar. EXR yığınına gömülü kod akışı, EXR başlığının bildirdiğinden farklı (daha küçük) döşeme/çizgi boyutları bildirebilir, ancak ht_undo_impl() bunu doğrulamaz; OpenJPH satır arabelleğinin gerçek uzunluğunu kontrol etmeden cur_line->i32[]'den genişlikte 32 bitlik örnekler çeker. Hazırlanmış bir EXR dosyası, ojph::local::codestream::finalize_alloc() tarafından tahsis edilen bir arabelleğin hemen ardından 4 baytlık bir yığın arabellek taşması READ üretir. Hataya, exr_decoding_run/Imf::checkOpenEXRFile tüketicisinin kullandığı standart tarama hattı-kod çözme giriş noktası aracılığıyla ulaşılabilir; bunlara küçük resim oluşturucular, varlık işlem hatları ve exrcheck yardımcı programı da dahildir; yani güvenilmeyen EXR dosyalarını açan herhangi bir uygulama. Sonuç, deterministik bir çökme (DoS) ve potansiyel bitişik yığın sızıntısıdır. Bu sorun 3.4.12 sürümünde giderilmiştir.
OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.11, the HTJ2K (High-Throughput JPEG 2000) decoder, ht_undo_impl() in OpenEXRCore is vulnerable to a heap-buffer-overflow READ. The ht_undo_imp function copies decoded pixels out of a per-line OpenJPH buffer using the EXR channel's declared width as the iteration count. The codestream embedded in the EXR chunk can declare different (smaller) tile/line dimensions than the EXR header advertises, but ht_undo_impl() does not validate this — it pulls width 32-bit samples from cur_line->i32[] without checking the OpenJPH line buffer's actual length. A crafted EXR file produces a 4-byte heap-buffer-overflow READ immediately after a buffer allocated by ojph::local::codestream::finalize_alloc(). The bug is reachable through the standard scanline-decode entry point used by every consumer of exr_decoding_run/Imf::checkOpenEXRFile, including thumbnailers, asset pipelines, and the exrcheck utility — i.e. any application that opens untrusted EXR files. The result is a deterministic crash (DoS) and potential adjacent-heap leak. This issue has been fixed in version 3.4.12.