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.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 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** 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.