Source: openimageio Version: 2.5.19.1+dfsg-2 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for openimageio. This is a substantial batch of CVEs, please help to properly assess them. CVE-2026-43903[0]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, sgiinput.cpp:265,274 use | OIIO_DASSERT for bounds checking in the RLE decode loop. In release | builds, OIIO_DASSERT compiles to ((void)sizeof(x)) (dassert.h:210), | making all bounds checks no-ops. A crafted .sgi file with RLE count | exceeding scanline width causes heap buffer overflow and crash. This | vulnerability is fixed in 3.0.18.0 and 3.1.13.0. CVE-2026-43904[1]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, softimageinput.cpp:469 (mixed RLE) | and :345 (pure RLE) do not clamp the run length to remaining | scanline width before writing pixels. The raw packet path (line 403) | correctly clamps with std::min, but RLE paths skip this check. A | crafted .pic file causes heap overflow up to 65535 bytes. This | vulnerability is fixed in 3.0.18.0 and 3.1.13.0. CVE-2026-43905[2]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, jpeg2000input.cpp:395 computes | buffer size as const int bufsize = w * h * ch * buffer_bpp using | signed 32-bit arithmetic. When the product exceeds INT_MAX, the | result wraps to 0 or a small value. m_buf.resize() allocates an | undersized buffer, and subsequent pixel write loops cause heap | overflow. Conditional on USE_OPENJPH build flag. This vulnerability | is fixed in 3.0.18.0 and 3.1.13.0. CVE-2026-43906[3]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, a heap-based buffer overflow in the | HEIF decoder of OpenImageIO allows out-of-bounds writes via crafted | images due to a subimage metadata mismatch, leading to memory | corruption and potential code execution. This vulnerability is fixed | in 3.0.18.0 and 3.1.13.0. CVE-2026-43907[4]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, a signed integer overflow in | QueryRGBBufferSizeInternal() in DPXColorConverter.cpp leads to a | heap-based out-of-bounds write when processing crafted DPX image | files. The function computes buffer sizes using 32-bit signed | integer arithmetic with negative multipliers (e.g., pixels * -3 * | bytes for kCbYCr descriptors and pixels * -4 * bytes for kABGR | descriptors), where a negative result is used as an in-band signal | that no separate buffer is needed. When the pixel count is | sufficiently large, the multiplication overflows INT_MIN and wraps | to a small positive value. The caller in dpxinput.cpp interprets | this positive value as a required buffer size, allocates an | undersized heap buffer via m_decodebuf.resize(), and then writes the | full image data into it via fread, resulting in a heap buffer | overflow. An attacker can exploit this by crafting a DPX file that | triggers the overflow, causing a denial of service (crash) or | potentially arbitrary code execution through heap corruption in any | application that reads pixel data using OpenImageIO. This | vulnerability is fixed in 3.0.18.0 and 3.1.13.0. CVE-2026-43908[5]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, a signed 32-bit integer overflow in | the pixel-loop index expression i * 3 inside ConvertCbYCrYToRGB() | causes the function to compute a large negative pointer offset into | the output buffer, producing an out-of-bounds write that crashes the | process. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0. CVE-2026-43909[6]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, a signed 32-bit integer overflow in | the loop index expression i * 4 inside SwapRGBABytes() causes the | function to compute a large negative pointer offset when processing | kABGR DPX images with large dimensions. The immediate crash is an | out-of-bounds read (the memcpy at line 45 reads from &input[i * 4] | first), but the subsequent write operations at lines 46–49 target | the same wrapped offset — making this a combined OOB read+write | primitive. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0. CVE-2026-43996[7]: | OpenImageIO is a toolset for reading, writing, and manipulating | image files of any image file format relevant to VFX / animation. | Prior to 3.0.18.0 and 3.1.13.0, the bounds check in | TGAInput::decode_pixel computes k + palbytespp as unsigned 32-bit | arithmetic. When k = 0xFFFFFFFC and palbytespp = 4, the addition | wraps to 0, which compares less than palette_alloc_size and passes | the check. The subsequent palette access uses the unwrapped k | (0xFFFFFFFC) as the index, reading ~4 GB past the start of the | palette buffer — SEGV. This vulnerability is fixed in 3.0.18.0 and | 3.1.13.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-43903 https://www.cve.org/CVERecord?id=CVE-2026-43903 [1] https://security-tracker.debian.org/tracker/CVE-2026-43904 https://www.cve.org/CVERecord?id=CVE-2026-43904 [2] https://security-tracker.debian.org/tracker/CVE-2026-43905 https://www.cve.org/CVERecord?id=CVE-2026-43905 [3] https://security-tracker.debian.org/tracker/CVE-2026-43906 https://www.cve.org/CVERecord?id=CVE-2026-43906 [4] https://security-tracker.debian.org/tracker/CVE-2026-43907 https://www.cve.org/CVERecord?id=CVE-2026-43907 [5] https://security-tracker.debian.org/tracker/CVE-2026-43908 https://www.cve.org/CVERecord?id=CVE-2026-43908 [6] https://security-tracker.debian.org/tracker/CVE-2026-43909 https://www.cve.org/CVERecord?id=CVE-2026-43909 [7] https://security-tracker.debian.org/tracker/CVE-2026-43996 https://www.cve.org/CVERecord?id=CVE-2026-43996 Regards, Salvatore
