Nicoppida

**Name of the Vulnerable Software and Affected Versions** libsixel versions prior to 1.8.7-r1 **Description** A use-after-free issue exists in the `load with gdkpixbuf()` function within `loader.c` when the software is built with the `--with-gdk-pixbuf2` option. The problem occurs because the cleanup path manually frees the `sixel frame t` object and its internal buffers without checking the reference count, despite the object being created via the refcounted constructor `sixel frame new()`. Consequently, any callback that uses `sixel frame ref(frame)` to maintain a reference will be left with a dangling pointer after `sixel helper load image file()` returns. An attacker can trigger this by providing a crafted image to an application built with gdk-pixbuf2 support, which may lead to memory corruption, information disclosure, or code execution. **Recommendations** Update to version 1.8.7-r1.

**Name of the Vulnerable Software and Affected Versions** libsixel versions prior to 1.8.7-r1 **Description** An integer overflow exists in the handling of the '--crop' option in img2sixel. When positive coordinates up to INT MAX are provided, the `sixel encoder do clip()` function fails to perform overflow-safe bounds checking. Specifically, the expression `clip w + clip x` can overflow to a large negative value if `clip x` is INT MAX, bypassing the bounds guard. This allows an unclamped coordinate to be passed through `sixel frame clip()` to `clip()`, which calculates a source pointer far beyond the image buffer and passes it to `memmove()`. An attacker can use a specially crafted crop argument with any valid image to trigger an out-of-bounds read in the heap, leading to a crash and potential information disclosure. **Recommendations** Update to version 1.8.7-r1.

**Name of the Vulnerable Software and Affected Versions** libsixel versions prior to 1.8.7-r1 **Description** An integer overflow exists in the `sixel frame convert to rgb888()` function within frame.c. This occurs when allocation size and pointer offset computations for palettised images (PAL1, PAL2, PAL4) use int arithmetic before casting to `size t`. For images with a pixel count exceeding INT MAX / 4, an undersized heap allocation is created for the conversion buffer and a negative pointer offset is generated for the normalization sub-buffer. Subsequently, the `sixel helper normalize pixelformat()` function writes full image data starting from the invalid pointer, leading to heap corruption. A specially crafted large palettised PNG can cause a process crash or potential arbitrary code execution. **Recommendations** Update to version 1.8.7-r1.

**Name of the Vulnerable Software and Affected Versions** libsixel versions prior to 1.8.7-r1 **Description** A use-after-free issue exists in the `sixel encoder encode bytes()` function. The `sixel frame init()` function stores the caller-owned pixel buffer pointer directly in `frame->pixels` without creating a defensive copy. When a resize operation occurs, `sixel frame convert to rgb888()` frees this caller-owned buffer and replaces it with a new internal allocation, resulting in a dangling pointer for the caller. Subsequent access to the original buffer can lead to a crash or potential code execution. An attacker controlling incoming frames can trigger this condition repeatedly. **Recommendations** Update to version 1.8.7-r1.

**Name of the Vulnerable Software and Affected Versions** libsixel versions prior to 1.8.7-r1 **Description** A Use-After-Free issue exists in the `load gif()` function within fromgif.c. This occurs because a single `sixel frame t` object is reused across all frames of an animated GIF, and the `gif init frame()` function frees and reallocates `frame->pixels` between frames without checking the object's reference count. Applications using `sixel helper load image file()` with a multi-frame callback to process user-supplied animated GIFs are affected. This can lead to a heap use-after-free when a callback uses `sixel frame ref()` to retain a frame and `sixel frame get pixels()` to access the raw pixel buffer, resulting in a dangling pointer after the second frame is decoded. This may cause a crash or potential code execution. **Recommendations** Update to version 1.8.7-r1.

Name of the Vulnerable Software and Affected Versions OpenEXR versions 3.4.0 through 3.4.7 Description OpenEXR, an image storage format used in the motion picture industry, contains a flaw where a specially crafted EXR file (B44 or B44A format) can lead to an out-of-bounds write during decoding via the `exr decoding run()` function. This can result in a crash or, potentially, corruption of heap allocations. Recommendations Update to OpenEXR version 3.4.8 or later.

Name of the Vulnerable Software and Affected Versions OpenEXR versions 3.4.0 through 3.4.6 Description OpenEXR, a specification and reference implementation of the EXR file format used in the motion picture industry, contains a flaw. A crafted .exr file utilizing HTJ2K compression and a channel width of 32768 can cause a heap buffer overflow when decoded by applications. This overflow occurs due to a write primitive of 2 or 4 bytes per iteration, repeating for each pixel exceeding the overflow point. This can lead to remote code execution. Recommendations Update to OpenEXR version 3.4.7 or later.

**Name of the Vulnerable Software and Affected Versions** SAIL (affected versions not specified) **Description** SAIL is a cross-platform library used for loading and saving images, supporting animation, metadata, and ICC profiles. The software contains a flaw due to the XWD parser's handling of the `bytes per line` value. This value, read directly from a file using the `io->strict read()` function, is used as the read size without validation against the destination buffer's size. An attacker can exploit this by providing a specially crafted XWD file with a large `bytes per line` value, leading to a heap-based buffer overflow during a write operation beyond the allocated memory for image pixels. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.